diff --git a/.changeset/pre.json b/.changeset/pre.json
index 667043df0e..78a71adc87 100644
--- a/.changeset/pre.json
+++ b/.changeset/pre.json
@@ -78,7 +78,8 @@
     "@objectstack/trigger-schedule": "16.1.0",
     "@objectstack/types": "16.1.0",
     "@objectstack/verify": "16.1.0",
-    "objectstack-vscode": "16.1.0"
+    "objectstack-vscode": "16.1.0",
+    "@objectstack/driver-turso": "17.0.0-rc.2"
   },
   "changesets": [
     "action-alias-conflict-warning",
@@ -86,6 +87,8 @@
     "action-body-type-gate",
     "action-body-write-set-lint",
     "action-crash-vs-rejection",
+    "action-ctx-session-contract",
+    "action-ctx-user-display-name",
     "action-execute-target-precedence",
     "action-governance-engine-owned",
     "action-location-dual-source-c17",
@@ -95,6 +98,8 @@
     "action-record-write-discarded-lint",
     "action-record-writes-runtime-report",
     "action-required-permissions-server-scope-docs",
+    "action-session-positions-canonical-roles-alias",
+    "action-session-positions-runtime-dual-emit",
     "action-strict-envelope-zero",
     "action-undoable-liveness-corrected",
     "actions-empty-object-segment-route",
@@ -105,9 +110,11 @@
     "adr-0044-revise-service-owned-note",
     "adr-0053-temporal-matrix-skewed-zone",
     "adr-0072-nav-target-refs",
+    "adr-0076-status-line-calibration",
     "adr-0078-completeness-gate",
     "adr-0078-phase3-webhook-triggers",
     "adr-0078-phase4-runtime-warns",
+    "adr-0078-status-calibration",
     "adr-0104-advertise-open-gates",
     "adr-0104-attestation-adr-note",
     "adr-0104-d1-media-strict-per-deployment",
@@ -131,6 +138,7 @@
     "adr-0104-remaining-flips-evidence",
     "adr-0104-remaining-flips-revision",
     "adr-0104-value-shapes-scan-gate",
+    "adr-0105-d6-unit-and-subordinates",
     "adr-0105-d8-delegated-admin-org-role",
     "adr-0105-d8-issuance-resolves-issuer-grants",
     "adr-0105-d9-cross-org-approver-targeting",
@@ -156,13 +164,16 @@
     "adr-0115-docs-tail-corrections",
     "adr-0115-plugin-dev-stub-table-verdict",
     "adr-0116-followups",
+    "adr-0117-owning-business-unit-name-reservation",
     "adr-0117-owning-business-unit",
     "adr-0118-non-user-actor-contract",
     "adr-0119-d2-migration-journal",
     "adr-0119-plugin-reachable-transactions",
+    "adr-0121-endpoint-routing-namespace",
     "adr-anchors-authz-sweep",
     "adr-anchors-guard",
     "adr0104-attest-after-boot-writes",
+    "adr0120-isolated-install-gate-and-truth-sweep",
     "agent-code-is-the-record",
     "agent-knowledge-alias-and-experimental-markers",
     "agents-md-worktree-staleness",
@@ -183,30 +194,59 @@
     "ai-surface-affinity-lint",
     "ai-tool-registry-and-lint",
     "ai-wildcard-to-zero",
+    "alias-integrity-direct-call-sites",
+    "alias-tables-are-claims-about-the-schema",
     "analytics-between-predicate-dropped",
+    "analytics-canonical-number-comparand",
     "analytics-capability-conditional-mounting",
     "analytics-client-dispatcher-alignment",
     "analytics-compare-measure-filters",
+    "analytics-contains-canonical-operator",
+    "analytics-cube-comparand-roundtrip",
     "analytics-cube-gate-and-error-leak",
+    "analytics-dataset-degradation-envelope-first",
+    "analytics-dataset-refusal-envelope",
+    "analytics-dimension-source-field-gate",
+    "analytics-echo-startswith-endswith",
     "analytics-effective-granularity",
+    "analytics-empty-combinator-identity",
     "analytics-empty-group-fill-compare-seam",
     "analytics-execute-aggregate-execution-context",
+    "analytics-face-refuses-uncompilable-filters",
+    "analytics-filter-normalizer-null-safe-negation",
+    "analytics-filter-not-null-safe-and-boolean-const",
     "analytics-filter-operator-coverage",
+    "analytics-filter-refusal-envelope",
+    "analytics-filter-value-type-fidelity",
     "analytics-label-read-scope",
+    "analytics-like-escape",
+    "analytics-notcontains-inert-predicate",
+    "analytics-null-comparand-predicate",
     "analytics-objectql-read-scope",
     "analytics-or-not-combinators",
     "analytics-order-by-display-label",
     "analytics-query-bare-shape-entry-validation",
+    "analytics-query-declared-fault-withhold",
+    "analytics-raw-sql-object-routing",
     "analytics-read-scope-bridge-order",
+    "analytics-read-scope-compile-failed-500",
     "analytics-record-scoping-and-measure-fields",
     "analytics-timedimension-projection",
+    "analytics-unlisted-refusal-envelope",
+    "analytics-where-filter-array-lowered",
+    "analytics-where-source-field-gate",
     "analytics-widget-query-options",
+    "analytics-window-timedimension-no-bucket",
     "api-exposure-failopen-observability",
+    "api-metadata-type-registry",
     "api-methods-derivation-contract",
     "apimethod-enum-shrink",
     "apimethods-batch-conformance-ratchet",
+    "apis-loud-reject-and-apiregistry-retirement",
+    "apis-publish-gates-flip",
     "app-area-fail-open-gates-removed",
     "app-dead-authoring-keys",
+    "app-form-tombstone-controls",
     "app-metadata-reference-integrity-assessment",
     "app-navigation-strict",
     "app-runtime-hooks-artifact-boot",
@@ -225,25 +265,42 @@
     "approval-pending-approver-groups",
     "approval-reassign-structured-parties",
     "approval-record-lock-predicate-updates",
+    "approval-revise-window-service-owned",
     "approval-status-mirror-names-the-actor",
     "approval-vocabularies-derived",
+    "approvals-admin-exemption-retired",
+    "approvals-engineless-resume-gap",
     "approvals-expose-lock-record",
     "approvals-payload-labels",
     "approvals-stranded-request-inspection",
     "approver-live-record-3447",
     "approver-value-sources-and-dead-slot-warning",
+    "apps-mdx-retired-version-mobile-navigation",
+    "area-prescription-both-trees",
     "array-form-triggertype-not-silent",
     "attachment-read-visibility-real-filter-semantics",
     "attachment-unscoped-multi-delete",
     "audit-anchor-and-lookup-integrity",
     "audit-provenance-and-import-vocabulary",
+    "audit-provisioning-datasource-audible",
+    "audit-skip-sys-job-queue",
+    "audit-skip-sys-upload-session",
     "audit-test-static-imports",
+    "auth-admin-audit-hook-bypass-claim-corrected",
     "auth-catchall-yields-unowned-paths",
+    "auth-contains-literal-substring",
+    "auth-database-hooks-middleware-claim-corrected",
+    "auth-invalid-membership-policy-outcome",
     "auth-lazy-cache-rate-limit-store",
+    "auth-membership-policy-setting",
     "auth-otp-budget-shared-counter-store",
     "auth-otp-cooldown-retention-follows-config",
     "auth-route-ledger",
+    "auth-unknown-subpath-clean-404",
     "auth-validationerror-4xx-mapping",
+    "auth-where-operator-coverage",
+    "authorable-surface-anchor-explicit",
+    "authorable-surface-anchor-monotonic",
     "authorable-surface-delete-proof",
     "authorable-surface-ratchet",
     "authoring-key-lint-full-coverage",
@@ -252,11 +309,13 @@
     "auto-org-admin-revoke-delete-signature",
     "automation-client-resume-screen-flow",
     "automation-resume-authority-gate",
+    "autonumber-runtime-owned-write-path",
     "banner-dsn-connection-display",
     "batch-create-readonly-ingress",
     "batch-dropped-fields-observability",
     "batch-row-error-codes-registered",
     "batch-row-result-schema-shape",
+    "batch-upsert-existence-fork",
     "better-auth-1-7-0-rc-2-and-prod-dep-batch",
     "better-auth-team-member-count",
     "blueprint-formula-expression",
@@ -264,20 +323,33 @@
     "body-write-lint-message-driver-truth",
     "book-job-translation-app-authorwarn-keys-retired",
     "boot-api-merge",
+    "boot-hydration-outage-diagnostic",
     "boot-hydration-scoped-lookup",
+    "brace-expansion-advisory-5-0-9",
+    "break-glass-standing-revocation-guard",
     "builtin-node-config-reconciliation",
+    "bulk-action-option-passthrough",
     "bulk-batch-size-cap",
     "bulk-data-event-contract",
+    "bulk-write-per-row-hook-semantics",
+    "bulk-write-previous-hook-condition-diagnostic",
+    "bulk-write-record-not-found",
     "bulk-writes-bind-to-path-object",
     "calendar-day-primitive-to-spec",
     "calendar-day-upper-bound-memory-mongodb",
     "calendar-day-upper-bound",
     "calldata-query-fallback-serves-query",
+    "calldata-record-not-found-unify",
+    "capabilities-registry-provenance-seam",
     "changelog-ships-in-tarball",
+    "chart-drilldown-declared",
+    "chart-drilldown-navigate-target",
     "chartconfig-trim-zoom-clickaction",
+    "check-docs-no-generator",
     "check-i18n-fails-on-undeclared-authoring-key",
     "check-mode-manifest-no-write",
     "ci-cache-tier1-optimizations",
+    "ci-filter-implicit-success-guard",
     "ci-merge-queue-throughput",
     "ci-node-22-pin",
     "ci-node-eol-guard",
@@ -285,12 +357,20 @@
     "ci-rerun-safety-and-timeouts",
     "ci-shard-test-core",
     "ci-test-completeness-guard",
+    "cli-banner-tenancy-posture",
+    "cli-email-provider-missing-api-key-throws",
+    "cli-format-zod-union-branches",
     "cli-json-pipe-truncation-sweep",
+    "cli-lazy-driver-sql-import",
+    "cli-libsql-url-inference",
+    "cli-sms-provider-unknown-tag-throws",
     "cli-stale-dist-tests-and-project-root",
     "client-actions-surface",
+    "client-delete-result-success",
     "client-error-envelope-normalisation",
     "client-keys-sharelinks-security",
     "client-meta-automation-descriptors",
+    "client-meta-getitem-saveitem-return-types",
     "client-packages-lifecycle",
     "client-react-bulk-data-hooks",
     "client-react-dependency-identity-loops",
@@ -304,9 +384,16 @@
     "close-the-eight-reports-rest-gaps",
     "close-the-final-nine-rest-gaps",
     "close-the-nine-metadata-rest-gaps",
+    "cluster-peer-write-invalidates-caches",
+    "code-only-metadata-types-refused-everywhere",
     "cold-boot-flow-bind-read-decorations",
+    "compose-stacks-no-silent-key-loss",
+    "config-resolution-email-example",
     "connector-authoring-guide",
+    "connector-degrade-cause",
     "connector-descriptors-meet-their-contract",
+    "connector-rate-limit-config-removed",
+    "connector-reconcile-fail-cause",
     "connector-template-cluster-removed",
     "console-09c6a177bb4a",
     "console-1bb77aa24514",
@@ -321,23 +408,37 @@
     "console-c6cfdf1288b6-backfill",
     "console-e651c936870e",
     "console-f5bc4c78be76",
+    "console-f995a452d2ca",
     "console-pin-pr-gate",
+    "control-byte-gate-scans-all-c0",
+    "control-byte-gate-scans-del",
     "control-flow-form-zod-ledger",
     "control-plane-guard-crossref",
+    "controlled-by-parent-master-sharing",
     "converge-activation-event-schema",
     "conversion-notice-channel",
+    "conversion-shadowed-alias-by-value",
     "criteria-json-declaratively-required",
     "cross-object-batch-501-code",
     "cross-repo-issue-closer",
     "current-user-endpoints-kernel-resolver",
     "d12-fake-inventory-gate",
+    "dangling-audit-provenance-bucket",
+    "dangling-audit-unscanned-bucket",
     "dashboard-strict",
+    "dashboard-widget-action-aria-removed",
+    "dashboard-widget-compareto-converged",
+    "dashboard-widget-responsive-removed",
     "data-driver-find-stream-retired",
+    "data-driver-query-omit-object",
     "data-event-contract",
     "data-field-changed-event-removed",
     "data-path-object-existence-gate",
     "data-query-path-object",
     "database-loader-ddl-failure-loud",
+    "database-loader-read-outage-is-not-a-miss",
+    "dataset-cross-datasource-compile-gate",
+    "dataset-dimension-field-descriptors",
     "dataset-percent-scale-chain",
     "dataset-query-strip-read-decorations",
     "datasource-admin-503-names-its-own-service",
@@ -352,6 +453,7 @@
     "datasource-read-replicas-removed",
     "datasource-retry-policy-retired",
     "datasource-routes-catch-service-throws",
+    "datasource-sqlite-pool-loud-reject",
     "datasource-teardown-ownership",
     "datasync-conflict-dual-source-c13-c15",
     "date-bucket-parity-gate",
@@ -359,55 +461,89 @@
     "datetime-canonical-utc-storage",
     "datetime-storage-form-memory-mongodb",
     "ddl-runtime-token-default",
+    "dead-scan-roots-hard-error-three-checks",
     "decision-branch-routing-enforced",
     "decision-output-required-pin",
     "decision-outputs-surface-3447",
     "declarative-cron-job-schedule-envelope",
+    "declarative-endpoints-docs-skill-catchup",
     "declared-unique-index-not-legacy",
     "default-datasource-adopt-seam",
     "default-datasource-declared",
+    "defer-adr0104-attestation-while-seed-in-flight",
     "define-hook-factory",
     "degraded-boot-stderr-premise",
+    "degraded-list-cache-policy",
+    "degraded-register-cause",
     "delegable-scope-read-surface",
+    "delete-fallback-success-shape",
     "delete-many-id-predicate",
     "department-approver-env-wide-business-unit",
     "deprecate-kernel-assignment-notifications",
     "deprecated-alias-conflict-rules",
+    "derived-capability-managed-by-guard",
+    "dev-fresh-claim-scope",
     "dev-plugin-production-hatch-brands",
     "dev-plugin-protocol-family-removed",
     "dev-plugin-security-stubs-and-prod-guard",
+    "dev-watcher-restart-honesty",
     "discovery-cache-queue-job-no-route",
     "discovery-data-slot-computed",
     "discovery-metadata-slot-computed",
+    "discovery-node-env-unset-production",
     "discovery-remedy-names-a-real-package",
+    "discovery-routes-mcp-declared",
+    "discovery-surface-schema-authoritative",
     "dispatcher-call-sites-meet-their-contracts",
     "dispatcher-envelope-shared-predicate",
     "dispatcher-error-code-is-semantic",
+    "dispatcher-fallback-absence-warn",
     "dispatcher-handler-ready-gate",
+    "dispatcher-per-request-kernel",
     "dispatcher-returned-error-leak",
     "dispatcher-validation-error-fields",
+    "doc-authoring-covers-claude-corpus",
+    "doc-authoring-dead-root-hard-error",
+    "doc-authoring-roots-docs",
+    "doc-formula-example-cel-gate",
     "doc-tags-connects-book-tag-include",
     "docs-accuracy-audit-4212-scope",
     "docs-audience-first-ia",
     "docs-audit-4161-service-automation",
     "docs-audit-changelog-non-exclusion",
+    "docs-audit-releases-read-only",
+    "docs-audit-scope-derived",
     "docs-drift-nested-package-roots",
     "docs-drift-skip-test-files",
     "docs-extend-faq-reversed-rot",
     "docs-fieldschema-extend-rot",
+    "docs-gen-module-description-selection",
+    "docs-gen-nested-brace-escape",
+    "docs-gen-numeric-literal-quoting",
+    "docs-gen-retired-key-never",
+    "docs-index-category-keyed",
     "docs-plugin-spec-onupgrade-example",
     "docs-v17-plugin-retirement-notes",
+    "doctor-config-env-overlay",
+    "doctor-config-load-cause",
+    "doctor-dotenv-provenance",
+    "doctor-installed-package-ledger-read-failure",
+    "doctor-optional-package-load-boundary",
+    "doctor-tenancy-posture-report",
     "document-weak-pass-variants",
     "dogfood-gate-cancelled-not-failure",
     "dogfood-shared-boot",
+    "dogfood-typecheck-wired",
     "domain-error-passthrough",
     "driver-capabilities-inert-bits-removed",
     "driver-conformance-gate",
     "driver-conformance-zero-discovery",
     "driver-connect-bound-and-reconnect-correction",
+    "driver-double-registration-log",
     "driver-options-bypass-tenant-audit",
     "driver-sql-logicalop-retention-note",
     "driver-sql-or-branch-and-semantics",
+    "drivers-dir-and-turso-migration",
     "drop-dead-env-template-flag",
     "drop-dead-list-templates",
     "drop-per-package-lint-scripts",
@@ -420,22 +556,49 @@
     "duplicate-fix-guard",
     "duplicate-package-flow-canonicalization",
     "durability-degradation-log-level",
+    "durability-gate-partial-recovery",
+    "durability-gate-savemetaitem",
     "durable-suspended-screen-refetch",
     "eighty-donkeys-repeat",
+    "eighty-months-obey",
+    "email-config-runtime-read-keys",
+    "email-durable-queue-delivery",
+    "email-outbox-boot-sweep",
+    "email-persist-config-carrier",
+    "email-persistence-insert-id-contract",
+    "email-provider-smtp",
     "email-template-materializer-bridge",
+    "embedded-host-unsealed-node-type-vocabulary-warns",
     "empty-capability-answers-501",
+    "empty-env-disabled-package-seed",
+    "empty-field-constraint-refused",
     "empty-group-bucket-key-null",
     "empty-state-gate-object-surface",
     "empty-state-semantics-gate",
+    "endpoint-chain-wiring",
+    "endpoint-execution-targets",
+    "endpoint-mapping-keys",
+    "endpoint-matcher-lazy-index",
+    "endpoint-mount-fallback-seam",
+    "endpoint-path-describe-carveout",
+    "endpoint-policy-keys",
+    "endpoint-publish-gate-backstop",
+    "endpoint-surfaces-announce-only-served",
     "enforce-user-level-export-axis",
     "engine-callsites-canonical-keys",
+    "engine-delete-dispatch-falsy-scalar-id",
+    "engine-double-delete-contract",
     "engine-filter-fold-every-method",
     "engine-rejects-unknown-option-keys",
     "engine-rejects-wire-only-aliases",
+    "engine-update-dispatch-predicate",
     "engines-node-22",
+    "env-settings-option-table-gate",
     "envelope-violations-predicate",
     "environment-artifact-dual-source-c10",
+    "etl-author-shape-aliases",
     "event-schema-dual-source-c6",
+    "executor-contract-surface-e1",
     "export-axis-opt-in",
     "export-empty-result-header",
     "export-honors-search-term",
@@ -445,33 +608,43 @@
     "fault-edge-guard-containment",
     "fault-edge-label-lint",
     "field-conditional-required-fold",
+    "field-expression-check-activated",
     "field-file-collection-dogfood-proof",
+    "field-mapping-transform-retired",
     "field-mapping-tri-source-c12",
     "field-readonly-doc-preserveaudit",
     "field-strict-guidance",
     "field-time-canonical-storage",
     "file-access-delegate",
+    "filewatch-degraded-not-announced",
     "filter-app-areas-nav-gate",
+    "filter-array-input-only-declaration",
+    "filter-array-lowered-at-engine-door",
     "filter-context-tokens-gate",
+    "filter-icontains-and-regex-retirement",
     "filter-logic-conformance-mongodb-wasm",
     "filter-logic-conformance-single-source",
     "filter-no-silent-drop",
     "filter-tokens-runtime-resolver",
     "find-data-wire-context",
     "findone-requires-a-predicate",
+    "five-pans-tease",
     "fix-cross-repo-closer-octokit",
     "fix-cross-repo-closer-require",
     "fix-stale-hono-changeset-ref",
     "fix-stale-scaffolder-changeset-refs",
     "fix-unmounted-local-file-url",
     "flow-action-record-id-seeding",
+    "flow-bind-warning-structured-issues",
     "flow-branch-gates-and-inert-condition",
     "flow-condition-bare-string-is-cel",
     "flow-create-record-write-lint",
+    "flow-crud-bulk-intent",
     "flow-error-object-serialization",
     "flow-executors-parse-config",
     "flow-filter-collapse-and-write-path-tokens",
     "flow-function-declared-effect",
+    "flow-lint-loop-body-descent",
     "flow-lookup-expand",
     "flow-max-retries-single-default",
     "flow-nested-region-walk",
@@ -480,25 +653,42 @@
     "flow-node-type-audit-at-boot-close",
     "flow-node-write-set-lint",
     "flow-run-summaries",
+    "flow-runas-unscoped-region-descent",
+    "flow-runas-unscoped-two-way-true-wording",
     "flow-system-run-audit-attribution",
     "flow-template-filter-position-severity",
     "flow-template-lint-and-hydrate-guards",
     "flow-template-paths-into-reference-integrity-suite",
+    "flow-time-relative-descriptor-lint",
     "flow-trigger-unknown-event-lint",
+    "flow-unbounded-bulk-write-lint",
     "form-layout-lint-wired",
     "form-section-pane",
+    "format-type-union-array-brackets",
+    "format-zod-error-union-branches",
+    "formula-canonical-parse-entry",
+    "formula-exists-means-has-a-value",
     "formview-buttons-defaults-live",
+    "fs-watch-invalidates-list-cache",
+    "gen-docs-passthrough-declared-shape",
+    "gentle-buttons-shave",
+    "gentle-pumas-repeat",
+    "getreadfilter-controlled-by-parent",
     "govern-remaining-nine-metadata-types",
     "govern-report-dashboard-liveness",
     "govern-sys-member-writes",
     "govern-webhook-liveness",
+    "great-buttons-tap",
     "group-key-read-shape",
     "group-union-driver-scope",
     "guard-refusal-chokepoint",
     "has-is-not-a-null-guard-lint",
+    "health-monitor-timeout-guard-cleared",
+    "hierarchy-scope-organization-authority",
     "historical-import-audit-docs",
     "homepageid-tombstone-premise-corrected",
     "honest-service-self-description",
+    "hono-adapter-handler-throw-logging",
     "hono-current-user-endpoints-exported",
     "hono-current-user-endpoints-ungated",
     "hono-retire-standard-endpoints",
@@ -510,13 +700,19 @@
     "hook-condition-fail-loud",
     "hook-condition-merged-record",
     "hook-condition-previous-binding",
+    "hook-context-session-positions-preserve-audit",
+    "hook-context-session-roles-retired",
     "hook-empty-target-not-wildcard",
+    "hook-logger-contract-shape",
     "hook-vs-flow-path-guidance",
     "host-app-resolver-shared",
+    "host-declared-package-resolution",
     "http-contract-unification",
+    "http-method-defkey-collision",
     "http-method-dual-source-c14",
     "http-protocol-discovery-two-shapes",
     "http-request-dual-source-c11",
+    "http-server-config-retired",
     "http-server-exemption-revoked",
     "hungry-donkeys-repeat",
     "i18n-bundle-drift-sweep",
@@ -533,43 +729,86 @@
     "i18n-translation-item-shape-3778",
     "i18n-translations-request-drop-phantom-filters",
     "i18n-view-coverage",
+    "i18n-walker-object-sections",
     "ihttpserver-contract-codify",
     "import-historical-audit",
     "import-historical-fsm",
     "import-sanitize-row-errors",
     "import-undo-preserveaudit",
+    "inbound-rate-limit-seam",
     "index-drift-migrate-plan",
+    "index-type-partial-removed",
     "inert-rule-warn-dedupe",
+    "infer-cube-array-where-parity",
+    "infer-cube-relation-traversal",
+    "init-service-contract-async-accessors",
     "init-service-declared-enforced",
+    "injected-system-columns-author-time",
     "inline-action-schema",
     "invitation-accepted-host-seam",
     "io-node-config-reconciliation",
     "isLikelyEmail-no-control-char",
     "job-placeholder-migrates-to-db-adapter",
+    "job-queue-completed-retention",
     "job-retry-timeout-3494",
     "job-runtime-create-closed",
+    "json-schema-rule-format-enforced",
+    "json-schema-rule-unknown-format-gate",
+    "jwt-eddsa-host-fallback",
+    "kernel-boot-hook-failure-propagation",
     "kernel-metadata-loader-envelope-removed",
+    "kernel-ready-unified-failure",
+    "kernel-shutdown-isolate-and-honest-timeout",
     "kernel-startup-timeout-guard-cleared",
     "keyset-batch-walks",
+    "knowledge-reap-guard-deindex",
+    "large-email-attachments-storage-refs",
+    "last-admin-ban-break-glass",
+    "last-admin-delete-break-glass",
+    "last-admin-guard-permission-set-row",
+    "layered-read-outage-is-not-no-overlay",
     "lazy-deps-dist-probe-timeout",
+    "ledger-readability-leaves-the-posture-gate",
+    "lifecycle-archive-abort-check",
     "lifecycle-event-registry-enforced",
+    "lifecycle-retention-floor",
+    "lifecycle-unguarded-reap-batching",
+    "lint-action-dedup-composite-key",
+    "lint-expressions-security-alias-reads",
     "lint-fieldless-object-skip",
     "lint-flag-record-change-trap",
+    "lint-never-fire-family-gates",
+    "lint-null-guards-canonical-parse",
     "lint-reference-integrity-suite",
+    "lint-rule-compilability-alias-read",
     "lint-searchable-fields-type-validation",
     "lint-system-fields-derived",
+    "lint-time-relative-scalar-unroutable",
+    "lint-translatable-sections",
     "lint-translation-reference-integrity",
     "lint-unique-double-declaration",
     "list-column-prefix-summary-object",
+    "list-single-flight",
+    "listcommits-outage-503",
     "liveness-evidence-path-resolution",
     "liveness-governs-every-registered-type",
     "liveness-ledger-ai-scope-honesty",
     "liveness-orphan-row-gate",
     "liveness-register-orphan-proofs",
+    "liveness-stale-evidence-fails-ci",
     "liveness-ten-preview-claims",
     "liveness-verified-at-clock",
+    "liveness-widget-drill-and-container-coverage",
+    "load-meta-hydration-benign-predicate",
     "localized-field-validation-messages",
+    "lock-gate-fail-closed",
+    "logger-redact-word-boundary",
+    "lost-audit-row-is-an-error",
+    "loud-pausing-resume-authority",
+    "mail-provider-options-honest",
     "manifest-bridge-arm-on-project-kernels",
+    "manifest-read-says-which-null",
+    "manifest-removal-gate",
     "many-data-atomic-real-or-refused",
     "mapping-agent-page-strict",
     "mapping-context-selector-unwarnable-keys-retired",
@@ -581,6 +820,9 @@
     "membership-grade-not-capability-channel",
     "memory-datasource-ephemeral-per-pool",
     "memory-driver-opt-in-persistence",
+    "memory-filter-refuse-what-it-cannot-evaluate",
+    "merge-dimension-key-unambiguous",
+    "merge-driver-worktree-independent",
     "messaging-declares-its-event-object",
     "messaging-outbox-no-updated-at-on-update",
     "meta-canonical-type-segment",
@@ -590,7 +832,11 @@
     "metadata-event-contract",
     "metadata-event-dual-source-kernel-side",
     "metadata-form-zod-reconciliation",
+    "metadata-get-diagnosed-outage-vs-miss",
+    "metadata-loader-delete-contract",
+    "metadata-loader-save-contract",
     "metadata-remove-artifact-api-source",
+    "metadata-store-outage-is-not-a-miss",
     "metadata-type-registration-names-a-real-hook",
     "metadata-unresolvable-posture-fail-closed",
     "metadata-watch-event-canonical-enum",
@@ -602,17 +848,26 @@
     "migrate-search-companion-parity",
     "migration-journal-boot-recovery",
     "modal-actions-are-client-only",
+    "mongodb-boolean-identity-reduction",
     "mongodb-single-tenant-boot-guard",
     "naming-drift-recheck",
     "nav-access-lint",
+    "nav-expanded-alias-cross-variant",
     "nav-item-input-type",
     "next-event-seq-read-failure-loud",
+    "node-and-shutdown-timeout-guards-cleared",
+    "notification-action-embed-config-retired",
     "notification-dual-source-c3",
     "notification-orphan-template-schemas",
     "notifications-redos-fix",
     "notify-source-shape-conversion",
+    "now-default-token-engine-resolved",
+    "nul-gate-covers-all-text",
+    "null-guard-surface-coverage",
+    "null-safe-org-unique-driver",
     "object-enable-trash-mru-migration-surface",
     "object-parse-path-strict",
+    "object-subblock-strictness-batch20",
     "objectchart-aggregate-result-columns",
     "objectchart-contract-back-to-spec-shape",
     "objectql-crossobj-capability",
@@ -620,37 +875,68 @@
     "objectql-dead-use-retired",
     "objectql-driver-connect-failfast",
     "objectql-engine-contract",
+    "objectql-retire-formula-now-snapshot-param",
     "objectql-strategy-daterange",
     "objectui-pin-changeset-from-declarations",
+    "objectui-pin-freshness-gate",
+    "objectui-range-from-declarations",
+    "olive-donkeys-repeat",
+    "olive-pugs-repeat",
+    "olive-pugs-sniff",
+    "openapi-builtin-routes-rest-owned",
+    "openapi-components-lazyschema-proxy",
+    "openapi-declared-endpoints",
+    "openapi-static-artifact-contract-only",
     "orderby-direction-vocabulary",
+    "org-axis-dead-alias-branches",
+    "org-axis-red-lines-read-spec-keys",
+    "org-create-effective-posture-gate",
     "osv-batch-2026-07-dep-bumps",
+    "osv-batch-2026-08-fixable-bumps",
+    "osv-exemption-conventions",
+    "otp-sms-quota-429",
+    "owning-business-unit-injection",
     "package-dependency-dual-source-c7",
     "packages-envelope-suite-comment",
     "page-field-and-chart-binding-lint",
     "page-header-i18n-3589",
+    "page-header-subtitle-alias-conversion",
     "paged-read-determinism",
     "pagination-filter-logic-driver-axis",
+    "parent-scoped-readonly-when-server-enforced",
     "per-package-typecheck-coverage",
     "permission-backfill-row-state-columns",
     "pin-control-flow-designer-forms",
     "platform-always-on-capabilities",
     "platform-objects-app-i18n-phantom-debt",
+    "plenty-poems-brush",
+    "plugin-dev-tenancy-d5-failfast",
     "plugin-lifecycle-hooks-retired",
     "plugin-ordering-declared-contract",
     "plugin-ordering-provider-declarations",
     "plugin-page-i18n-drift-guard",
+    "plugin-startup-log-cause",
+    "pm-dev-discipline-2026-08-04",
     "pm-dispatch-2026-08-03-ops-lessons",
     "pm-dispatch-agent-tooling",
     "pm-dispatch-domain-lanes",
+    "pm-dispatch-domain-table-full-coverage",
     "pm-dispatch-escalation-bar",
     "pm-dispatch-round1-lessons",
+    "pm-dispatch-three-axis-decision-frame",
+    "pm-dispatch-triage-execution-split-seat-registry",
     "pm-dispatch-triage-lessons",
     "pm-dispatch-triage-tooling",
+    "pm-findings-discipline",
+    "posture-misreads-sweep",
+    "prerelease-pin-watch-probe",
     "preserveaudit-test-and-docs",
     "preview-omits-virtual-fields",
     "previous-null-on-create-leg",
     "prose-example-gate-covers-docs",
     "protection-envelope-invariant-was-hollow",
+    "protocol-17-area-caveat-corrected",
+    "provision-hostname-assignment",
     "prune-aspirational-config-3494",
     "prune-dead-audit-config-cluster",
     "prune-dead-capabilities-descriptor",
@@ -661,36 +947,55 @@
     "prune-report-column-grouping-schemas",
     "prune-skill-permissions",
     "public-book-grant",
+    "publish-draft-drain-discriminate",
+    "publish-drafts-endpoint-gate",
+    "publish-drafts-partial-unhide",
     "published-files-whitelist",
     "published-pm-dispatch-skill",
+    "published-pm-dispatch-three-axis-decision-frame",
     "purge-webhook-delivery-i18n-and-bundle-ownership-guards",
     "query-ast-inert-request-surface",
     "query-cursor-removed",
     "query-distinct-removed",
     "query-field-node-object-form-removed",
     "query-having-enforced",
+    "quick-melons-swim",
+    "quiet-ledgers-speak-up",
+    "rare-jars-shave",
     "rate-limit-config-dual-source-c9",
     "rbac-objects-bulk-primitive",
     "react-block-field-props-lint",
     "react-blocks-declaration-parity-not-conformance",
+    "react-chart-aggregate-parse-gate",
+    "react-declaration-parity-cannot-run-is-not-a-skip",
     "react-listview-searchable-fields-lint",
     "react-page-props-joins-the-suite",
     "react-tier-record-blocks-withdrawn",
+    "read-diagnostics-union-branches",
+    "read-scope-not-null-safe-and-empty",
+    "read-scope-null-safe-negative-operators",
     "readme-fde-audience",
     "readonly-flow-write-json-warning",
     "readonly-flow-write-lint",
     "readonly-flow-writes-joins-the-suite",
+    "readonly-strip-actionable-warning",
     "ready-probe-driver-health",
+    "reap-guard-intersection-composition",
     "reconcile-ledger-in-ci",
     "reconcile-packages-post-and-ui-view-dialect",
     "record-after-write-trigger",
     "record-change-hydrate-formula-fields",
+    "record-delete-share-cascade",
+    "record-details-sections-object-form",
+    "record-highlights-field-readonly",
     "recorded-by-nullable-lookup",
     "recursive-schema-input-pins",
     "recursive-schema-input-types",
     "reference-id-embedded-record",
     "reference-integrity-object-and-action-names",
     "reference-integrity-wiring-guard",
+    "refuse-out-of-contract-filter-input",
+    "refused-capability-declaration-hole",
     "regenerate-ui-action-reference-doc",
     "region-metadata-parity",
     "region-slots-single-declaration",
@@ -712,8 +1017,11 @@
     "request-body-schema-validation",
     "required-decision-outputs",
     "resolve-service-returns-its-contract",
+    "rest-4xx-message-truncate-not-replace",
+    "rest-5xx-message-withheld",
     "rest-actions-type-dispatch",
     "rest-env-resolution-kernel-resolver-seam",
+    "rest-expected-4xx-not-logged-as-unhandled",
     "rest-list-implicit-filter-and-merge",
     "rest-list-malformed-filter-rejected",
     "rest-list-search-groupby-aggregations-rejected",
@@ -722,6 +1030,8 @@
     "rest-patch-data-dropped-fields",
     "rest-route-ledger-audit-guard",
     "rest-server-openapi31-block-removed",
+    "rest-unclassified-error-server-fault-status",
+    "rest-union-branch-field-errors",
     "resume-gate-map-chain-and-reserved-vars",
     "resume-signal-chokepoint",
     "retire-activation-events",
@@ -741,15 +1051,21 @@
     "retire-the-dispatcher-auth-mock",
     "retire-three-deprecated-aliases",
     "retire-three-orphan-operator-vocabularies",
+    "retired-keys-exact-registry",
     "retirement-prescriptions-name-protocol-17",
     "retry-policy-dual-source-c8",
+    "retry-vocab-converge-inline-blocks",
     "rls-enabled-enforced-security-audit",
+    "rls-predicate-authoring-gate",
     "rls-priority-removed",
+    "root-reference-index-generated",
     "route-audit-tranche-3-service-mounts",
     "route-envelope-four-more-modules",
     "route-envelope-guard-dispatcher-domains",
     "route-ledger-audit-guard",
     "rpc-alias-precedence-one-fold",
+    "rule-compilability-publish-gate",
+    "rule-id-barrel-export-gap",
     "run-summary-uncountable-effects",
     "runner-setters-first-wins",
     "runtime-action-execution-module",
@@ -760,15 +1076,22 @@
     "runtime-domain-body-extraction",
     "runtime-domain-extraction-batch3",
     "runtime-domain-handler-registry",
+    "runtime-httpserver-wrapper-retired",
     "runtime-meta-data-extraction",
     "runtime-overlay-not-artifact",
     "runtime-packages-extraction",
     "runtime-share-links-extraction",
+    "runtime-typecheck-wired",
     "sandbox-structured-error-passthrough",
     "save-flow-canonicalization-fallback-warning",
+    "save-legacy-raw-engine-branch-removed",
     "save-meta-item-flow-canonicalization",
+    "save-meta-response-full-fields",
+    "savemeta-422-union-branch-issues",
     "savemeta-persists-normalized-operators",
+    "scaffold-remote-template-namespace",
     "scaffolds-drop-memory-driver",
+    "schema-drift-runtime-managed-index",
     "schema-name-suffix-strip",
     "schemaless-node-config-contracts",
     "schemaless-node-expression-ledger",
@@ -777,17 +1100,22 @@
     "screen-field-visible-when-on-the-wire",
     "screen-resume-declared-field-contract",
     "script-branch-keys-retired",
+    "sdui-component-props-gate",
     "searchable-fields-stale-declaration",
     "security-get-readable-fields",
     "security-props-liveness-recheck",
     "security-service-contract",
+    "seed-autonumber-read-outage",
     "seed-datasets-multitenant-replay-union",
     "seed-env-enforced",
     "seed-insert-replay-lint",
     "seed-loader-composite-external-id",
     "seed-loader-dropped-reference-counter",
     "seed-loader-engine-schema-fallback",
+    "seed-loader-loud-failure-log-level",
     "seed-loader-multi-value-lookup",
+    "seed-loader-stale-summary-counter",
+    "seed-loader-unresolved-record-drop-loud",
     "seed-replay-tenant-stamp",
     "seed-state-machine-lint",
     "seed-summary-banner",
@@ -800,66 +1128,105 @@
     "serve-no-artifact-definestack-pin",
     "serve-organizations-host-resolution",
     "serve-organizations-mount-vs-import",
+    "serve-tenancy-posture-boot-gate",
+    "service-datasource-vitest-testtimeout",
     "service-error-envelope-conformance",
     "service-lookup-any-guard",
     "service-storage-success-envelope",
     "session-dual-source-c4",
+    "session-of-record-is-sys-session",
     "settings-error-details-declared-slot",
+    "settings-select-options-enforced",
+    "share-link-record-existence",
     "share-link-routes-envelope",
     "share-links-dispatcher-dual-key",
     "shared-response-envelope-builders",
     "sharing-access-level-full-removed",
+    "sharing-hierarchy-org-authority",
+    "sharing-rule-bulk-write-recompute",
     "sharing-rule-criteria-required",
     "sharing-rule-recipient-reconcile",
     "sharing-rule-unknown-sort-and-stale-help",
+    "sharing-rule-unlowerable-condition-gate",
     "sharing-rule-withdrawal-and-delete",
     "showcase-action-disabled-specimen",
     "showcase-approver-and-picker-specimens",
     "showcase-bulk-actions-example",
+    "showcase-contact-field-groups",
+    "showcase-declarative-endpoints-restored",
     "showcase-global-action-specimen",
+    "showcase-inert-wirings",
+    "showcase-inquiry-purge-bulk-intent",
     "showcase-legacy-rowactions-specimen",
     "showcase-nav-affordance-specimen",
+    "showcase-register-contact-views",
+    "single-delete-binds-previous",
+    "sink-engine-dispatch-to-metadata-core",
+    "skill-formula-condition-abort-scope",
     "skill-hook-condition-aborts",
+    "skill-instructions-as-mcp-prompts",
     "skills-definehook-examples",
     "slot-contract-ledger-beyond-the-enum",
     "slot-lookup-fourth-shape",
     "slot-lookup-ratchet-enforcement",
     "slot-lookup-sweep-auth-session",
+    "slot-lookup-sweep-rest-composition-root",
     "slot-lookup-type-argument-ratchet",
     "slot-lookups-return-their-contract",
+    "sms-daily-send-quota",
+    "smtp-transport-plugin-email",
     "sort-dotted-path-rejected",
+    "sort-node-direction-rejected",
     "spec-api-surface-baseline-percent-scale",
+    "spec-artifacts-sharded-by-category",
     "spec-changes-manifest-catchup",
     "spec-check-generated-aggregate",
+    "spec-filter-logic-conformance-null-column",
     "spec-generated-merge-driver",
+    "spec-offline-surface-anchor",
     "spec-property-retirement-skill",
     "spec-vitest-testtimeout",
+    "sql-driver-boolean-identity",
     "sql-driver-dialect-connect-timeout",
+    "sql-driver-not-null-safe",
+    "sql-driver-null-safe-negative-operators",
     "sqlite-datetime-date-bucket",
     "sqlite-wal-journal-mode",
+    "sso-register-gate-one-admin-grade-ruler",
     "stack-storage-not-an-authoring-key",
     "stall-forensics-and-kernel-test-hygiene",
     "stall-guard-rollout",
+    "stall-guard-self-test",
     "standard-endpoints-parity-correction",
     "standard-endpoints-precedence-pin",
     "startup-log-noise-cleanup",
     "startup-registry-verdict-guard",
     "step2-metadata-protocol-plugin",
     "step2-prc-single-source",
+    "storage-adapter-list-implementations-removed",
     "storage-adapter-swap-verdict",
     "storage-download-filename",
+    "storage-local-root-env-channel",
+    "storage-metadata-loud-failure",
+    "storage-service-list-retired",
     "stored-metadata-replays-the-chain",
     "stored-migration-covers-flows",
+    "strict-automation-control-flow-state-machine",
     "strict-object-registered-types",
+    "strict-readonly-writes",
     "strictness-ledger-gate",
+    "strictness-ledger-numbers-prose-split",
     "strictness-ledger-recursive-coverage",
     "strictness-ledger-remeasure",
     "strip-read-decorations-on-save",
     "studio-strict",
+    "summary-count-zero-on-parent-insert",
     "summary-index-registry-revision",
     "sweep-close-out",
     "sys-comment-record-level-authorization",
     "sys-comment-retire-visibility-reply-count",
+    "sys-email-headers-attachments",
+    "sys-metadata-repo-history-counters-loud",
     "sys-migration-ledger-platform-infra",
     "sys-secret-store-platform-infra",
     "sys-view-definition-default-open",
@@ -874,18 +1241,29 @@
     "temporal-storage-form-axis-tests",
     "temporal-time-axis",
     "tenancy-default-org-fail-closed",
+    "tenancy-modes-doc-posture-rewrite",
+    "tenancy-tenantfield-no-default",
     "tenant-plan-dual-source-c16",
     "tender-donkeys-smoke",
     "tender-hats-brush",
     "test-core-stall-guard",
     "tests-off-memory-driver",
+    "theme-inert-token-scales-removed",
+    "thick-pumas-judge",
+    "tidy-donkeys-yawn",
     "tidy-eyes-shine",
     "tombstone-agent-tools",
     "tool-inert-keys-removed",
     "tool-requires-confirmation-not-enforced",
     "tool-requires-confirmation-removed",
+    "transaction-degrade-and-cross-datasource-observability",
     "translation-groups-strict",
+    "translation-refs-container-default-form-sections",
     "trigger-registry-connector-cluster-removed",
+    "turso-remote-canonical-temporal-backfill",
+    "turso-remote-node-operator-refusal",
+    "turso-remote-null-safe-negation",
+    "turso-remote-pagination-tiebreaker",
     "two-factor-lockout-and-object-translations",
     "two-factor-lockout-extension",
     "two-factor-lockout-follows-settings",
@@ -894,19 +1272,38 @@
     "typecheck-covers-the-test-layer",
     "typed-decision-outputs-3447",
     "ui-discovery-reads-the-protocol-service",
+    "ui-interaction-config-family-retired",
     "ui-vocabularies-derive-not-restate",
+    "undefined-comparand-refusal",
+    "unified-capability-vocabulary",
+    "unique-scope-lint-rules",
+    "unique-scope-organization-vocabulary",
     "unique-tenant-scoped-materialization",
     "unknown-authoring-key-lint",
     "unknown-key-lint-nested-descent",
+    "unknown-key-strictness-automation-batch11",
+    "unknown-key-strictness-automation-etl",
+    "unknown-key-strictness-automation-node-config",
     "unknown-key-strictness-data-step",
     "unknown-key-strictness-step2",
     "unknown-key-strictness-step3",
     "unknown-key-strictness-tier-a",
+    "unknown-key-strictness-ui-batch13",
+    "unknown-key-strictness-ui-batch14",
+    "unknown-key-strictness-ui-batch15",
+    "unknown-key-strictness-ui-batch16",
+    "unknown-key-strictness-ui-batch17",
     "unknown-node-config-key-warning",
+    "unknown-object-heuristic-attribution",
     "unordered-paged-read-determinism",
+    "unregister-invalidate-after-delete",
+    "update-data-id-scalar-test",
+    "update-prior-read-per-object",
     "update-record-dropped-field-warnings",
+    "updatemany-idless-row-guard",
     "url-field-accepts-relative-urls",
     "user-field-implicit-target",
+    "user-filters-allow-add-tab-promote-and-close",
     "user-less-run-data-ops-refused",
     "user-level-export-axis",
     "v17-dissolve-protocol-alias",
@@ -925,21 +1322,34 @@
     "validate-runs-build-authoring-lints",
     "validation-kind-retired",
     "validation-variants-strict",
+    "vama-write-path-bypass",
     "variant-doc-drift-gate",
     "variant-docs-exemption-audit",
     "verify-harness-durable-suspended-runs",
     "verify-multitenant-requests-isolated-posture",
     "view-ast-operator-parity",
+    "view-filter-rule-console-id-hotfix",
+    "view-label-resolve-served-shape",
     "view-strict-final",
+    "view-subblock-strictness-batch18",
+    "views-translation-key-runtime-identity",
     "wait-loose-config-graduation",
+    "wait-node-log-cause-meta",
     "wait-timeout-keys-retired",
+    "wait-timer-job-released-with-the-pause",
+    "wait-timer-store-unavailable-keeps-job",
+    "warn-undeclared-resume-authority",
     "wasm-sqlite-returning-writes-persist",
     "webhook-authoring-surface-bridge",
     "webhook-dual-source-api-side",
     "webhook-liveness-ledger-flip",
     "webhooks-drop-dead-delivery-i18n",
+    "widget-contract-performanceconfig",
+    "widget-contract-theme-token-vocabulary",
     "wildcard-fallthrough-guard",
     "withdraw-adr-0107-drop-writes-proposal",
-    "workflow-slot-retired"
+    "workflow-slot-retired",
+    "workflow-status-function-gate",
+    "write-response-formula-hydration"
   ]
 }
diff --git a/examples/app-crm/CHANGELOG.md b/examples/app-crm/CHANGELOG.md
index 6446489e6a..828a19bbf4 100644
--- a/examples/app-crm/CHANGELOG.md
+++ b/examples/app-crm/CHANGELOG.md
@@ -1,5 +1,150 @@
 # @objectstack/example-crm
 
+## 4.0.92-rc.3
+
+### Patch Changes
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [da5d1b4]
+- Updated dependencies [d4e0809]
+- Updated dependencies [739f496]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [64cd010]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [9f747ee]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [43ca399]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [7bf3d1c]
+- Updated dependencies [db9c331]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [217b791]
+- Updated dependencies [fd8521f]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [18b8eaa]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [78adc2e]
+- Updated dependencies [81e2744]
+- Updated dependencies [277eb36]
+- Updated dependencies [41e605e]
+- Updated dependencies [2649ccb]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [a70cd0a]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [d9971d3]
+- Updated dependencies [d9cac60]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [1203bb2]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [2ddba89]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [ef7845a]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [0cd08d5]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [5aaa6fc]
+- Updated dependencies [dca5bd3]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/runtime@17.0.0-rc.4
+
 ## 4.0.92-rc.2
 
 ### Patch Changes
diff --git a/examples/app-crm/package.json b/examples/app-crm/package.json
index 6ab24c3626..d91d200577 100644
--- a/examples/app-crm/package.json
+++ b/examples/app-crm/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/example-crm",
-  "version": "4.0.92-rc.2",
+  "version": "4.0.92-rc.3",
   "description": "Minimal CRM example — a smoke-test workspace that exercises the metadata loading pipeline (objects → views → app → dashboard → hook → flow → seed). For a full-featured enterprise CRM see https://github.com/objectstack-ai/hotcrm.",
   "license": "Apache-2.0",
   "private": true,
diff --git a/examples/app-showcase/CHANGELOG.md b/examples/app-showcase/CHANGELOG.md
index 15e8dfe7dd..ec8117da13 100644
--- a/examples/app-showcase/CHANGELOG.md
+++ b/examples/app-showcase/CHANGELOG.md
@@ -1,5 +1,258 @@
 # @objectstack/example-showcase
 
+## 0.3.14-rc.3
+
+### Patch Changes
+
+- 3905c00: feat(objectql)!: a predicate bulk write evaluates and fires after-hooks PER ROW (#5038)
+
+  The 2026-08-04 maintainer ruling on #4800 / #4862, recorded as ADR-0058's
+  bulk-write addendum: **a bulk write is N record changes**, so every record-scoped
+  declaration on it is evaluated per row — `record` = that row's state, `previous` =
+  that row's pre-write state. Validation predicates have worked this way since
+  #3106; hook `condition`s and the record-change flow triggers riding the same
+  lifecycle hooks now join them.
+
+  **What was broken.** A `multi: true` update reaches `driver.updateMany`, which
+  resolves an affected COUNT. The lifecycle hook fired **once**, `previous` was
+  never assigned (only the single-id branch fetched a prior row), and `record`
+  degraded to the write's bare payload. So the transition condition the docs, the
+  formula skill and ten showcase flows all teach —
+  `status == "done" && previous.status != "done"` — could not be evaluated on a
+  bulk write. Hook conditions rejected the write (#4775/#5037); record-change flow
+  triggers were **silent**, firing zero times or once for a record that did not
+  exist. A missing audit row is the one failure nobody goes looking for.
+
+  **What changed.** The engine's bulk `update` / `delete` branches now read the
+  matched row set **once** — the same `driver.find` #3106 already issues, with
+  "this object has after-hooks" added to its demand test — and dispatch
+  `afterUpdate` / `afterDelete` once per matched row, each on a context with the
+  **single-record shape**: `input.id` = the row, `previous` = its pre-image,
+  `result` = its state. That is #2922's batch-INSERT ruling restated, and it is why
+  this fix has no code in the consumers: `hook-wrappers`' `record`/`previous`
+  bindings, the record-change trigger's context builder and plugin-audit's diff all
+  read those same fields and became correct at the producer.
+
+  - **Per-row dispatch is uniform across after-hooks.** It is deliberately NOT
+    keyed on whether a condition mentions `previous` — the ruling rejected that as
+    a hidden rule that would make a hook's firing count depend on its condition
+    text.
+  - **`ctx.result` per row is the ROW**, composed as `row ⊕ payload` from the
+    pre-image already in hand, so the batch still costs one extra query, not one
+    per row. A bulk DELETE has no post-state: its per-row context sets no `result`,
+    and consumers fall back to `previous`.
+  - **`onError` needed no new meaning** — it governs a handler on a record-scoped
+    context, which is now what it always gets: `abort` fails the operation, `log`
+    swallows that row and the batch continues.
+  - **A ceiling, enforced as a refusal.** Past 10 000 matched rows a predicate
+    write against an object with after-hooks is rejected _before_ the driver call
+    (`ERR_BULK_PER_ROW_HOOK_LIMIT`), so nothing is written. It is never downgraded
+    to one dispatch for the batch — that would skip the hook for N-1 rows silently.
+
+  **Breaking for hook authors, in the direction the contract declares.** An
+  after-hook on an object that takes predicate writes now runs once per matched row
+  instead of once per batch: a notification hook sends N messages, a
+  cache-invalidation hook runs N times. Objects with no after-hooks are untouched
+  and pay for no extra read. The write's own contract is unchanged — a predicate
+  write still resolves the affected count and still publishes ONE aggregate
+  `data.records.updated` (#4639).
+
+  **`before*` hooks stay batch-scoped, and that is not a gap.** `beforeUpdate` /
+  `beforeDelete` fire once for the whole batch because they may still rewrite the
+  payload, and one `updateMany` carries one payload. #5037's `HookConditionError`
+  and its `limitation` discriminator therefore **survive, rescoped to that
+  dispatch** — with a message that no longer promises an expiry that has already
+  happened, names the phase as the reason, and points at the matching `after*`
+  event where the same condition evaluates per row as authored. It also now names a
+  record-change flow trigger as a real route: #5037 refused to, on measured
+  evidence that the trigger shared the same unbound `previous`; that fact changed.
+
+  Docs (`data-modeling/formulas.mdx`) and `skills/objectstack-formula` §5 are
+  updated to teach one transition shape for both write forms, with the `before*`
+  exception called out.
+
+- 9f41ee6: test(e2e,showcase): showcase 的 `apis:` 回迁,并由真实 boot 探针证明它真的在服务(#5040 E8)
+
+  #4936 把 showcase 的两条声明式端点注释掉,不是因为它们写错了,而是因为当时整条端点链零执行:没有任何路由为声明的 `path` 挂载,没有匹配器,每一个键 —— 包括 `authRequired` —— 解析通过而不生效。那时候留着它们就是在演示一个运行时不兑现的能力(Prime Directive #10)。
+
+  #5040 的 E1–E7 把执行器建起来、把整面硬拒收窄成逐端点 publish 门之后,那条理由不复存在。本单按**原意**恢复这两条 —— 同名、同 target、同 `authRequired`、同 `cacheTtl` —— 只做 ADR-0121 D1 要求的一处修改:路径迁进本应用的命名空间保留区。
+
+  ```
+  - path: '/api/v1/showcase/tasks'
+  + path: '/api/v1/apps/showcase/tasks'
+
+  - path: '/api/v1/showcase/inquiries/purge'
+  + path: '/api/v1/apps/showcase/inquiries/purge'
+  ```
+
+  这处修改不是装饰:`manifest.namespace: 'showcase'` 从此是发布的前置条件(声明了 `apis:` 却没有显式 namespace 会被 publish 拒绝),而 `apps/{namespace}/` 这一段让路由归属变成结构性的 —— 没有任何内建域住在 `apps/` 下,两个包也不可能因为 namespace 不同而撞车。
+
+  **匿名面没有增加**:两条历史声明本来就都是 `authRequired: true`,回迁后仍然是。一个例子不该长出它从来没有过的公开面。
+
+  coverage 清单里 `apis` 从 `waived` 翻回 `demonstrated`,理由重写为「由真实 boot 测量」而不是「声明即证明」—— 后者正是 #4936 抓到的那类假覆盖。支撑它的是两份新的真实 boot e2e:showcase 那份走真实 artifact 摄入路径,证明匹配命中执行(find 的 data 与内建 `/data` 路由逐字节相同)、匿名 401、`cacheTtl` 只随成功答案上线、挂载点下未声明路径与挂载点外的裸 404 完全一致、`/meta/api` 与 `/openapi.json` 描述的正是挂载的东西;fixture 那份补上 ADR-0121 D6 的匿名分支 —— 省略 `authRequired` 拒绝匿名、显式 `false` 服务匿名、已装配预算耗尽后 429 且 `Retry-After` 真的在线上。
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [da5d1b4]
+- Updated dependencies [d4e0809]
+- Updated dependencies [739f496]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [64cd010]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [9f747ee]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [43ca399]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [99d7a93]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [7bf3d1c]
+- Updated dependencies [db9c331]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [217b791]
+- Updated dependencies [fd8521f]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [06ba036]
+- Updated dependencies [18b8eaa]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [78adc2e]
+- Updated dependencies [0f17114]
+- Updated dependencies [81e2744]
+- Updated dependencies [277eb36]
+- Updated dependencies [41e605e]
+- Updated dependencies [2649ccb]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [a70cd0a]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [c7406b0]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [d9971d3]
+- Updated dependencies [d9cac60]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [b508244]
+- Updated dependencies [5a45b9b]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [26e1029]
+- Updated dependencies [4addd9d]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [1203bb2]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [2ddba89]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [ef7845a]
+- Updated dependencies [7127b48]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [9c5abf4]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [0cd08d5]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [f98fa65]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [cba7454]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [193cd5c]
+- Updated dependencies [5aae790]
+- Updated dependencies [07f1822]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [5aaa6fc]
+- Updated dependencies [dca5bd3]
+- Updated dependencies [c89d18c]
+- Updated dependencies [acf34e3]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/runtime@17.0.0-rc.4
+  - @objectstack/cloud-connection@17.0.0-rc.4
+  - @objectstack/driver-sql@17.0.0-rc.4
+  - @objectstack/service-datasource@17.0.0-rc.4
+  - @objectstack/connector-mcp@17.0.0-rc.4
+  - @objectstack/connector-openapi@17.0.0-rc.4
+  - @objectstack/connector-rest@17.0.0-rc.4
+  - @objectstack/connector-slack@17.0.0-rc.4
+
 ## 0.3.14-rc.2
 
 ### Patch Changes
diff --git a/examples/app-showcase/package.json b/examples/app-showcase/package.json
index 851e7e639f..375e8e7c6d 100644
--- a/examples/app-showcase/package.json
+++ b/examples/app-showcase/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/example-showcase",
-  "version": "0.3.14-rc.2",
+  "version": "0.3.14-rc.3",
   "description": "Kitchen-sink showcase workspace — exercises every metadata type, every view type, every chart type, and the major end-to-end capability chains (security, automation, analytics). Built for demonstration, debugging, and coverage-driven verification.",
   "license": "Apache-2.0",
   "private": true,
diff --git a/examples/app-todo/CHANGELOG.md b/examples/app-todo/CHANGELOG.md
index f0ade14509..1b10b22cc2 100644
--- a/examples/app-todo/CHANGELOG.md
+++ b/examples/app-todo/CHANGELOG.md
@@ -1,5 +1,201 @@
 # @objectstack/example-todo
 
+## 4.0.92-rc.3
+
+### Patch Changes
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [da5d1b4]
+- Updated dependencies [d4e0809]
+- Updated dependencies [739f496]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [64cd010]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [9f747ee]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [c497d26]
+- Updated dependencies [bbdbf28]
+- Updated dependencies [2e284b2]
+- Updated dependencies [3905c00]
+- Updated dependencies [4335497]
+- Updated dependencies [43ca399]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [aa25a81]
+- Updated dependencies [3a18e24]
+- Updated dependencies [533a0a4]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [947d4f9]
+- Updated dependencies [d8f65fe]
+- Updated dependencies [58ffcab]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [3133cda]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c794f78]
+- Updated dependencies [7bf3d1c]
+- Updated dependencies [db9c331]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [217b791]
+- Updated dependencies [fd8521f]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [2b63a00]
+- Updated dependencies [06ba036]
+- Updated dependencies [18b8eaa]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [78adc2e]
+- Updated dependencies [81e2744]
+- Updated dependencies [277eb36]
+- Updated dependencies [41e605e]
+- Updated dependencies [ecc61ab]
+- Updated dependencies [2649ccb]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [a70cd0a]
+- Updated dependencies [c52e608]
+- Updated dependencies [afa6aa5]
+- Updated dependencies [afb83d3]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [2b2175b]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [c7406b0]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [729a43a]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [d9971d3]
+- Updated dependencies [d9cac60]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [290d944]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [5d3ced9]
+- Updated dependencies [44106d9]
+- Updated dependencies [1eadac0]
+- Updated dependencies [7c2f7dd]
+- Updated dependencies [9b26699]
+- Updated dependencies [95b4f0d]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [b5459bc]
+- Updated dependencies [1624f4a]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [26e1029]
+- Updated dependencies [1cae606]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b9cc17d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [1203bb2]
+- Updated dependencies [7d27da0]
+- Updated dependencies [0d24078]
+- Updated dependencies [089767f]
+- Updated dependencies [5b8f95b]
+- Updated dependencies [2ddba89]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [ef7845a]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [37a8f2b]
+- Updated dependencies [441d79f]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [0cd08d5]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [2680cd3]
+- Updated dependencies [c5a5996]
+- Updated dependencies [db2ea82]
+- Updated dependencies [51a587d]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [d56bcdb]
+- Updated dependencies [dca25e1]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [5aaa6fc]
+- Updated dependencies [dca5bd3]
+- Updated dependencies [488b66c]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [e92e2c3]
+- Updated dependencies [946a131]
+- Updated dependencies [909895d]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+- Updated dependencies [2b52bc8]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/runtime@17.0.0-rc.4
+  - @objectstack/metadata@17.0.0-rc.4
+  - @objectstack/objectql@17.0.0-rc.4
+  - @objectstack/client@17.0.0-rc.4
+  - @objectstack/driver-sqlite-wasm@17.0.0-rc.4
+  - @objectstack/service-knowledge@17.0.0-rc.4
+  - @objectstack/mcp@17.0.0-rc.4
+  - @objectstack/knowledge-memory@17.0.0-rc.4
+
 ## 4.0.92-rc.2
 
 ### Patch Changes
diff --git a/examples/app-todo/package.json b/examples/app-todo/package.json
index 7caa51c353..7eff4ded9f 100644
--- a/examples/app-todo/package.json
+++ b/examples/app-todo/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/example-todo",
-  "version": "4.0.92-rc.2",
+  "version": "4.0.92-rc.3",
   "description": "Example Todo App using ObjectStack Protocol",
   "license": "Apache-2.0",
   "private": true,
diff --git a/examples/embed-objectql/CHANGELOG.md b/examples/embed-objectql/CHANGELOG.md
index 4bb21cbd69..b0e1a9e308 100644
--- a/examples/embed-objectql/CHANGELOG.md
+++ b/examples/embed-objectql/CHANGELOG.md
@@ -1,5 +1,165 @@
 # @objectstack/example-embed-objectql
 
+## 0.0.32-rc.3
+
+### Patch Changes
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [f7df82c]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [d085670]
+- Updated dependencies [de70b42]
+- Updated dependencies [01c0bae]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [c497d26]
+- Updated dependencies [bbdbf28]
+- Updated dependencies [2e284b2]
+- Updated dependencies [3905c00]
+- Updated dependencies [4335497]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [947d4f9]
+- Updated dependencies [d8f65fe]
+- Updated dependencies [58ffcab]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [2b63a00]
+- Updated dependencies [06ba036]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [0f17114]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [afa6aa5]
+- Updated dependencies [afb83d3]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [c7406b0]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [d9971d3]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [290d944]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [5d3ced9]
+- Updated dependencies [1eadac0]
+- Updated dependencies [7c2f7dd]
+- Updated dependencies [9b26699]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [60a7a2d]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [26e1029]
+- Updated dependencies [1cae606]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b9cc17d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [0d24078]
+- Updated dependencies [089767f]
+- Updated dependencies [5b8f95b]
+- Updated dependencies [2ddba89]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [37a8f2b]
+- Updated dependencies [441d79f]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [9c5abf4]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [2680cd3]
+- Updated dependencies [c5a5996]
+- Updated dependencies [db2ea82]
+- Updated dependencies [51a587d]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [d56bcdb]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [488b66c]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [946a131]
+- Updated dependencies [909895d]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+- Updated dependencies [2b52bc8]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/driver-memory@17.0.0-rc.4
+  - @objectstack/objectql@17.0.0-rc.4
+
 ## 0.0.32-rc.2
 
 ### Patch Changes
diff --git a/examples/embed-objectql/package.json b/examples/embed-objectql/package.json
index b8a8dafb44..a09e0e5f8c 100644
--- a/examples/embed-objectql/package.json
+++ b/examples/embed-objectql/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/example-embed-objectql",
-  "version": "0.0.32-rc.2",
+  "version": "0.0.32-rc.3",
   "private": true,
   "description": "Embed the ObjectQL engine as a plain library via @objectstack/objectql/core — no kernel, no plugins, no metadata protocol (ADR-0076).",
   "type": "module",
diff --git a/packages/adapters/hono/CHANGELOG.md b/packages/adapters/hono/CHANGELOG.md
index c02940da9e..b6b75ffd9c 100644
--- a/packages/adapters/hono/CHANGELOG.md
+++ b/packages/adapters/hono/CHANGELOG.md
@@ -1,5 +1,48 @@
 # @objectstack/hono
 
+## 17.0.0-rc.4
+
+### Patch Changes
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [da5d1b4]
+- Updated dependencies [739f496]
+- Updated dependencies [28ad90e]
+- Updated dependencies [64cd010]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [9f747ee]
+- Updated dependencies [43ca399]
+- Updated dependencies [eda599e]
+- Updated dependencies [7bf3d1c]
+- Updated dependencies [db9c331]
+- Updated dependencies [77022a9]
+- Updated dependencies [217b791]
+- Updated dependencies [fd8521f]
+- Updated dependencies [18b8eaa]
+- Updated dependencies [78adc2e]
+- Updated dependencies [81e2744]
+- Updated dependencies [277eb36]
+- Updated dependencies [41e605e]
+- Updated dependencies [2649ccb]
+- Updated dependencies [a70cd0a]
+- Updated dependencies [08f93bc]
+- Updated dependencies [d9cac60]
+- Updated dependencies [dfa8bad]
+- Updated dependencies [02dc076]
+- Updated dependencies [55dbbba]
+- Updated dependencies [1203bb2]
+- Updated dependencies [caf144a]
+- Updated dependencies [2ddba89]
+- Updated dependencies [ef7845a]
+- Updated dependencies [0cd08d5]
+- Updated dependencies [ae490ef]
+- Updated dependencies [5aaa6fc]
+- Updated dependencies [dca5bd3]
+- Updated dependencies [aac90a5]
+  - @objectstack/runtime@17.0.0-rc.4
+  - @objectstack/types@17.0.0-rc.4
+  - @objectstack/plugin-hono-server@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Patch Changes
diff --git a/packages/adapters/hono/package.json b/packages/adapters/hono/package.json
index ee5c13b9cc..d6c1cfe9ef 100644
--- a/packages/adapters/hono/package.json
+++ b/packages/adapters/hono/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/hono",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",
diff --git a/packages/apps/account/CHANGELOG.md b/packages/apps/account/CHANGELOG.md
index 43a52c824a..471a56e9c3 100644
--- a/packages/apps/account/CHANGELOG.md
+++ b/packages/apps/account/CHANGELOG.md
@@ -1,5 +1,130 @@
 # @objectstack/account
 
+## 17.0.0-rc.4
+
+### Patch Changes
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [d9971d3]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [e98fb14]
+- Updated dependencies [1b9a53b]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [f104bab]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/platform-objects@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Patch Changes
diff --git a/packages/apps/account/package.json b/packages/apps/account/package.json
index b2af6e8a0e..9051960598 100644
--- a/packages/apps/account/package.json
+++ b/packages/apps/account/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/account",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "ObjectStack Account — the end-user account/self-service console app, packaged as its own ObjectStack app package (ADR-0048: one app per package).",
   "main": "dist/index.js",
diff --git a/packages/apps/setup/CHANGELOG.md b/packages/apps/setup/CHANGELOG.md
index f6be3312d7..03fb082f3b 100644
--- a/packages/apps/setup/CHANGELOG.md
+++ b/packages/apps/setup/CHANGELOG.md
@@ -1,5 +1,130 @@
 # @objectstack/setup
 
+## 17.0.0-rc.4
+
+### Patch Changes
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [d9971d3]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [e98fb14]
+- Updated dependencies [1b9a53b]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [f104bab]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/platform-objects@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Patch Changes
diff --git a/packages/apps/setup/package.json b/packages/apps/setup/package.json
index bce539fd62..4a0ca4aa59 100644
--- a/packages/apps/setup/package.json
+++ b/packages/apps/setup/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/setup",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "ObjectStack Setup — the platform administration app, packaged as its own ObjectStack app package (ADR-0048: one app per package).",
   "main": "dist/index.js",
diff --git a/packages/apps/studio/CHANGELOG.md b/packages/apps/studio/CHANGELOG.md
index 6bb8152f1b..91a889d056 100644
--- a/packages/apps/studio/CHANGELOG.md
+++ b/packages/apps/studio/CHANGELOG.md
@@ -1,5 +1,130 @@
 # @objectstack/studio
 
+## 17.0.0-rc.4
+
+### Patch Changes
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [d9971d3]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [e98fb14]
+- Updated dependencies [1b9a53b]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [f104bab]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/platform-objects@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Patch Changes
diff --git a/packages/apps/studio/package.json b/packages/apps/studio/package.json
index aea1f99533..ad0081b01e 100644
--- a/packages/apps/studio/package.json
+++ b/packages/apps/studio/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/studio",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "ObjectStack Studio — the metadata builder app, packaged as its own ObjectStack app package (ADR-0048: one app per package).",
   "main": "dist/index.js",
diff --git a/packages/cli/CHANGELOG.md b/packages/cli/CHANGELOG.md
index 55b3d3b1a2..506076a48d 100644
--- a/packages/cli/CHANGELOG.md
+++ b/packages/cli/CHANGELOG.md
@@ -1,5 +1,1946 @@
 # @objectstack/cli
 
+## 17.0.0-rc.4
+
+### Major Changes
+
+- bcfebb0: fix(cli,plugin-email)!: `OS_EMAIL_PROVIDER=resend/postmark` without an API key now fails the boot instead of silently becoming the log transport (#5132)
+
+  **BREAKING for one configuration: a delivery provider selected without the
+  credential it needs.** `os serve` used to answer that by rewriting `provider` to
+  `log`, printing a warning, and booting normally. The result was a server that
+  accepted every send, recorded each one in `sys_email` as sent, and delivered
+  nothing — the warning scrolled past in CI logs and the truth surfaced when a
+  user reported never receiving a verification code. #5087 closed exactly this gap
+  inside `@objectstack/plugin-email` (`makeTransport` throws rather than
+  substituting a transport); the CLI's own capability assembly kept doing it one
+  layer up, for `resend` / `postmark`.
+
+  `resolveEmailCapabilityArg` now refuses every mail configuration it cannot
+  deliver through, the way its neighbouring `smtp` arm already did:
+
+  - `resend` / `postmark` with no `OS_EMAIL_API_KEY` (or `config.email.apiKey`);
+  - a `provider` tag outside `log` / `smtp` / `resend` / `postmark` — including
+    the retired `sendgrid` / `ses`, which get their SMTP migration in the message.
+
+  **Who is affected:** deployments (typically CI or preview environments) that set
+  `OS_EMAIL_PROVIDER=resend` or `=postmark` without a key and relied on the
+  fallback to boot. Nothing else changes — a complete configuration is passed
+  through untouched, and an unset `OS_EMAIL_PROVIDER` still defaults to `log`.
+
+  **Migration — one line, either direction:**
+
+  - the environment is _not_ meant to send mail → `OS_EMAIL_PROVIDER=log`
+    (that explicit value is the supported way to say so, and why refusing the
+    others is fair);
+  - the environment _is_ meant to send mail → set `OS_EMAIL_API_KEY` (or
+    `config.email.apiKey`).
+
+  Both errors name the consequence and both fixes, per AGENTS.md's
+  degradation-log-level rule.
+
+  `@objectstack/plugin-email` gains the vocabulary the CLI reads instead of
+  restating: `API_KEY_EMAIL_PROVIDERS`, `emailProviderRequiresApiKey()` and the
+  `ApiKeyEmailProvider` type, alongside `EMAIL_TRANSPORT_PROVIDERS` /
+  `isEmailTransportProvider` / `unsupportedProviderFix` from #5094. One vocabulary,
+  two consumers, pinned by a contract test — a second literal list in the CLI is
+  how the settings dropdown and the transports drifted apart in the first place.
+
+- de770bf: fix(cli,service-sms)!: `OS_SMS_PROVIDER=twilo` now fails the boot instead of silently becoming the log transport (#5713)
+
+  **BREAKING for one configuration: a provider tag no SMS transport can build.**
+  `os serve` used to hand `OS_SMS_PROVIDER` (or `config.sms.provider`) straight to
+  `SmsServicePlugin` with nothing to compare it against. The plugin then caught the
+  `makeSmsTransport: unknown provider 'twilo'` throw, substituted `LogSmsTransport`,
+  and booted normally — measured, not inferred:
+
+  ```
+  new SmsServicePlugin({ provider: 'twilo' }).init(ctx)
+    booted_without_throw: true            transport_class: 'LogSmsTransport'
+    isConfigured():       false           logger.warn × 1, logger.error × 0
+    service.send(…)    →  { status: 'sent', messageId: 'dev-sms-…' }
+  ```
+
+  So a phone-OTP sign-in answered "code sent", the user waited for an SMS that was
+  never dispatched, and the one `warn` line scrolled past in the boot log. That is
+  the declared-but-not-delivered shape of Prime Directive #10, and the same one
+  #5132 closed for **mail** in the neighbouring arm of the very same capability
+  loop.
+
+  Three gates already guard the `sms` provider value and none of them could see
+  this path: the `sms` settings namespace declares `provider` as a `select` with an
+  options table, #5131 enforces that table on the write path, and #5204 closed the
+  `SettingsService` env-override branch. All three live behind `SettingsService` —
+  this read happens while the kernel is being assembled, _before_ a settings
+  service exists.
+
+  **`resolveSmsCapabilityArg` now refuses a provider tag outside
+  `log` / `aliyun` / `twilio`**, the way its neighbouring `resolveEmailCapabilityArg`
+  already did, and the capability loop turns that into the loud failure it should
+  be — a hard boot error when the app declared `requires: ['sms']`, otherwise a
+  `console.error` and no SMS service.
+
+  **What it deliberately does NOT do:** demand credentials. Unlike mail, SMS
+  provider credentials are not a boot-time input — the `sms` settings namespace
+  binds them at `kernel:ready`, and that is their documented home. A bare
+  `OS_SMS_PROVIDER=twilio` on a host whose Twilio keys live in Settings is a
+  complete configuration and passes through untouched. `SmsServicePlugin`'s own
+  fallback is likewise untouched: for a _known_ provider with incomplete
+  constructor credentials it is correct (the settings bind can still swap in a
+  working transport), and it remains the last line of defence for hosts that
+  construct the plugin themselves. `os serve` simply stops feeding it input it can
+  never use.
+
+  **Who is affected:** deployments that set `OS_SMS_PROVIDER` (or
+  `config.sms.provider`) to a value outside the supported three — in practice a
+  typo, or a provider that was never implemented — and relied on the fallback to
+  boot. An unset `OS_SMS_PROVIDER` still defaults to `log`; every supported tag
+  still boots with or without credentials.
+
+  **Migration — one line, either direction:**
+
+  - the environment is _not_ meant to send SMS → `OS_SMS_PROVIDER=log` (that
+    explicit value is the supported way to say so, and why refusing the others is
+    fair);
+  - the environment _is_ meant to send SMS → fix the tag to `aliyun` or `twilio`
+    and put the credentials in Settings → SMS Delivery (or
+    `config.sms.providerOptions`).
+
+  The error names the consequence and both fixes, per AGENTS.md's
+  degradation-log-level rule.
+
+  `@objectstack/service-sms` gains the vocabulary the CLI reads instead of
+  restating: `SMS_TRANSPORT_PROVIDERS` and `isSmsTransportProvider()`, with
+  `SmsProviderTag` now derived from the array rather than declared beside it. One
+  vocabulary, two consumers — a second literal list in the CLI is how the mail
+  settings dropdown and the mail transports drifted apart in the first place
+  (#5094).
+
+### Minor Changes
+
+- 28ad90e: feat(types,cloud-connection,lint,cli): ADR-0120 17.x 收尾 —— `isolated` 安装期姿态硬门(D5e)、D5c 重拼写 advisory、成文契约扫荡与三姿态 conformance (#5081)
+
+  ADR-0120 17.x 波的第三块,也是最后一块。前两块已在 main 上:#5212(driver 侧
+  D3+D4 —— `COALESCE(organization_id, '__global__')` 物化、drift 两侧同步、重复预检)
+  与 #5208(spec 词汇 `'organization'` + D5a/D5b lint)。本次补齐三件事:安装期的
+  姿态决策点、剩余的成文契约、以及把「一个 app 包跑遍三种姿态」从假设变成测试。
+
+  **D5e —— 装进 `isolated` 环境时的硬门。** 词汇本身是姿态无关的:作者说的是业务
+  边界(`'organization'` 一个组织一份 / `'global'` 整个安装一份),没有任何索引形状
+  读姿态。唯一的残留在一个方向上:`isolated` 下组织就是**不同客户**,此时 app 业务
+  对象上的 `'global'` 唯一既跨客户过度约束,又变成跨客户的存在性预言机(S10/S14)。
+  维护者裁定这是**硬门而非 advisory**:把带 `'global'` 唯一(非 `sys` 对象)的 app
+  装进 `isolated` 环境会**停下来并逐索引列出**,安装者(通常是 AI agent)要么确认它
+  确实是平台级的,要么改写为 `'organization'`;确认按 ADR-0104 attestation 风格
+  留痕在安装清单里(`InstalledManifestEntry.globalUniqueAttestation` —— 确认了什么、
+  谁确认的、何时、在哪个姿态下问的),**之后不复问**。
+
+  - 停下的安装**什么都不留**:先于 hot-register 和任何 ledger 写入,所以作者改完
+    元数据可以直接重试,不需要先卸载。
+  - 逐索引确认是有牙齿的:`confirmGlobalUniques` 收 `true` 或明确的 id 数组,只确认
+    其中一条仍会在剩下的那条上停住。
+  - 升级引入的**新**约束会被问,老的答案继续算数。
+  - 另一个姿态下给出的确认**不算同意** —— `isolated` 那个问题在 `single` 下从未被
+    问过,所以按「未确认」处理(唯一不会静默放行跨客户约束的方向)。
+  - ⛔ **永不做成启动期告警**(#4884 纪律)。boot 时的 rehydrate 不评估此门;门够不到
+    的两类存量 —— 门禁上线前的安装、装后姿态变更的环境 —— 由 `os doctor` 与
+    `os migrate plan` 的 advisory 形态覆盖。
+
+  判定里有三条是承重的,别「简化」掉:声明索引上的裸 `unique: true` **算**(D1 说它
+  就是 `'global'` 的位置式拼写,排除它等于让整个 17.x 可以靠拼写绕过);字段级
+  `true` **不算**(它是 `'organization'`,永久合法);`sys_`/`base_` 对象**不算**
+  (S5 那批引擎幂等键天然就是平台级的,每次安装都问一遍就是 #4884 的误报类)。
+
+  CLI: `os package install` 新增 `--confirm-global-uniques`,并把 409 渲染成可读的
+  逐条清单而不是一句 "Install failed (409)"。
+
+  **D5c —— 遗留手写组织复合索引的 advisory。** 新规则
+  `unique/legacy-organization-composite`:声明的唯一索引自己列出了组织列
+  (`{ fields: ['name','organization_id'], unique: true }`)—— 这是词汇出现之前手写
+  per-organization 的写法。它读起来像「每组织唯一」,物化出来却是普通复合索引,而
+  SQL UNIQUE 是 NULL-distinct 的:组织列为 NULL 的行上它**什么都不约束**(#5030),
+  在单组织部署上那就是每一行。改写成 `unique: 'organization'`(`fields` 原样保留,
+  driver 会把已列出的组织列**就地**变成 NULL-safe 形式)正是补上这个洞的动作。
+  **永远只是 advisory,永远不自动修**:老拼写永久合法、零强制 drift,而 opt-in 是
+  真实的物理收紧,要走 D4 的 `recreate_index` + 重复预检。
+
+  **D6 —— 成文契约扫荡。** `content/docs/data-modeling/indexing.mdx` 的
+  §Two ways to say "unique" 全节按新词汇重写(含 `os:check` 代码块);
+  `content/docs/protocol/objectql/schema.mdx` 的 §Uniqueness and tenancy 重写为
+  §Uniqueness and scope —— 其中那句「单租户部署不受影响,租户列是常量,复合索引
+  退化为单列索引」是 #5030 **证伪过的原话**,现已替换为 D3 的 NULL-safe 事实;
+  `content/docs/deployment/cli.mdx` 的 `replace_unique_index` / `recreate_index`
+  条目补上 NULL-safe 形状与重复预检;`content/docs/references/**` 经
+  `gen:schema && gen:docs` 再生成,未手改。
+
+  按 ADR-0120 Resolved #2 的非规范性引导(官方示例/脚手架/生成器在新代码中输出
+  显式拼写),`skills/objectstack-data/**` 的索引与校验规则整体扫过:声明索引一律
+  说清 scope,并新增一节完整讲 `'organization'` 的 NULL-safe 语义与「永远不写姿态」。
+  顺带修掉那里长期使用的 `tenant_id` —— 平台的列叫 `organization_id`。
+  `examples/**`、`create-objectstack` 模板与 `os generate` 经核查**根本没有声明任何
+  唯一约束**,故无可扫;这是核查结论,不是遗漏。
+
+  **三姿态 conformance(ADR §Acceptance tests)。** 同一个 fixture app 在
+  `single | group | isolated` 三姿态下启动,逐 S 行用**真实的违规插入**断言 enforcement
+  (S1/S2/S3/S4/S5/S6/S7/S8/S9/S11/S12),并逐姿态捕获物化出的索引键,断言三者
+  **逐字节相同** —— 「没有任何索引形状读姿态」这句话一旦有两者不同就是假的。相同性
+  断言配了一条正向断言(对着期望的键形状),这样「三次都什么都没建」不会读成「一致」。
+  外加 ADR 只要的那一条 transition smoke:在 `single` 下建库、`isolated` 下重新打开,
+  drift op 为零。
+
+  对既有部署的影响:除新增的安装期确认外,本次不改变任何已有物化行为。字段级
+  `unique: true` 一如既往合法。
+
+- 29f30c0: feat(cli): `libsql://` URLs boot a Turso driver — via an optional package, never a silent SQLite fallback (#5602)
+
+  `os start --database libsql://my-db.turso.io --database-auth-token $TURSO_TOKEN`
+  是 `os start --help` 自己列出的 example,但在此之前它必然 `exit 1`:CLI 的
+  URL → driver 推断认得 `libsql://`,却当场抛 `UnsupportedDriverError` —— 而 runtime 的
+  环境 provisioning 把 turso 排在偏好第一位。两处口径相反的原因(driver 不在开源分发里)
+  已随 #4645 把 `@objectstack/driver-turso` 迁回本仓而消失。
+
+  现在这条 example 成真:
+
+  - **识别即构造。** `libsql://` / `*.turso.io` 解析为 `turso` datasource 定义,
+    `--database-auth-token`(`OS_DATABASE_AUTH_TOKEN`,回落到 vendor 自己的
+    `TURSO_AUTH_TOKEN`)进入 driver 配置 —— 该 flag 此前只被转发进子进程环境、无人读取。
+  - **可选依赖 + 动态 import。** `@objectstack/driver-turso` 声明为 CLI 的
+    **optional peer**(它会拖入 `@libsql/client`),默认安装体积不变;只有真正选了 libSQL
+    的启动才会动态 import 它,并通过 `DefaultDatasourcePlugin` 既有的 host-factory 接缝注入。
+    连接路径、`bootCritical` 失败裁决、`OS_ALLOW_DRIVER_CONNECT_FAILURE` 逃生舱与
+    Setup → Datasources 的状态留存因此与其他 driver 完全一致(#3826)。
+  - **包缺席时响亮失败。** 抛 `MissingDriverPackageError`,消息给出精确安装命令
+    (`npm install @objectstack/driver-turso`)、说明它是 optional peer,并说明为什么
+    ⛔ 不回退 SQLite:静默降级会让服务器对着一个空的本地库启动,而你的 libSQL 数据原封不动,
+    每一次写入都落在错误的数据库里(#3276 的教训)。
+  - **仍然拒收的形状。** `--database-driver turso` 但没有任何 URL —— libSQL 没有可猜的默认值,
+    这条继续抛 `UnsupportedDriverError`,而不是悄悄用 SQLite 默认值顶上。
+
+  `os start` 的 example 加了「需安装 driver 包」注记,Drivers / Self-hosting /
+  Environment variables / CLI 四处文档同步为「可选包支持」口径。
+
+- db9c331: fix(runtime,cli): 未设置 `NODE_ENV` 时 `/discovery` 不再自称 `development`,统一按 `production` 解读 (#5673)
+
+  同一个「宿主没有设置 `NODE_ENV`」的事实,仓里原本有两套相反的默认:`os start` 未设时强制
+  `NODE_ENV='production'`(`start.ts:248`),`os serve` 与 `os doctor` 按
+  `NODE_ENV || 'production'` 解析 `.env*` 级联,而 `/discovery` 的 `environment` 字段
+  直接把缺省读成 `development`。
+
+  **为什么这个方向的错报是危险的那个。** `environment` 是**机器可读面**上的字段,客户端
+  拿它回答「我在不在生产环境」,并可能据此不显示生产警示、放宽破坏性操作的二次确认。一个
+  忘记设 `NODE_ENV` 的真实生产部署,过去会拿到 `development` —— 两种错法里代价更高的那种。
+  按 maintainer 2026-08-06 裁定,缺省统一收敛到保守值 `production`。
+
+  **迁移说明(行为变更,请对照自己的部署方式读)**
+
+  - **生产部署忘设 `NODE_ENV`**:`/discovery` 的 `environment` 由 `development` 变为
+    `production`。这正是本次修复的目标 —— 报的是实情,不需要任何动作。
+  - **本地开发**:不受影响。`os dev` 会 spawn `serve --dev`,而 `serve` 在 `--dev` 且
+    `NODE_ENV` 未设时就地设 `NODE_ENV='development'`(`serve.ts:490-491`),所以
+    `pnpm dev` / `pnpm dev:showcase` / `dev:crm` / `dev:todo` 链路上 `NODE_ENV` 早已是
+    显式的 `development`,`/discovery` 仍报 `development`。没有任何脚本因此改动。
+  - **需要 `development` 却不走 `os dev` 的场景**(裸 `os serve`、以库形式内嵌运行时、
+    自建容器入口):现在必须显式 `NODE_ENV=development`。这是本次唯一需要动手的一类。
+  - **已设置的合法拼法一律不变**:`production`/`prod` → `production`,
+    `staging`/`sandbox` → `sandbox`,`development`/`dev`/`test` → `development`。
+  - **无法识别的拼法处置不回退**:`qa`、`preview`、`uat` 这类**设了但认不出**的值仍然
+    降级为 `development`,#4828 的「绝不凭猜测宣称 production」保持原样。缺省不是猜测,
+    是宿主选择不说 —— 两条是不同的规则,本次只动前者。
+
+  **`os doctor` 新增一行提示。** `NODE_ENV` 未设时报
+  `NODE_ENV  Not set — this environment is being treated as production`(warning,不影响
+  退出码),`--verbose` 展开显式设置的两条命令。已设置的环境完全没有这一行,报告与从前
+  逐字一致。统一默认让缺省变得**安全**,但也让「疏忽」和「有意的生产部署」变得无法区分;
+  这一行是唯一能把两者分开的地方。
+
+  **已知残留(已另开 #5936 跟进,本次不动)。** `/discovery` 有两个生产者。本次改的是
+  `@objectstack/runtime` 的 `HttpDispatcher.getDiscoveryInfo()`;经 `@objectstack/rest`
+  暴露的 `MetadataProtocol.getDiscovery()`(`packages/metadata-protocol`)把真实缺省原样
+  递给共享映射函数,该函数对缺省仍返回 `development`。裁定把落点限定在 runtime 侧、把
+  `packages/metadata-protocol` 标为跨域文件面,所以此处如实记录而非顺手绕过。
+
+- 9c4f174: feat(plugin-email): durable email delivery through `sys_job_queue`, opt-in (#5160)
+
+  `IEmailService.send()` has always delivered **inline**: the SMTP session ran
+  inside the caller's `await`, and `EmailService`'s retry loop lived in the same
+  process — so a crash between the attempt and the retry dropped the message with
+  no trace beyond a `sys_email` row stuck at `queued`. The pieces for a durable
+  path all existed (`sys_job_queue`, the `DbQueueAdapter`, an `email.send.async`
+  subscriber) but nothing in the repo ever published to that topic.
+
+  **New: `queueDelivery`.** With it on, `send()` persists the `sys_email` row,
+  publishes an `email.send.async` job **referencing that row**, and returns
+  `{ status: 'queued' }` immediately. A worker delivers the row and finalizes it
+  in place (`sent` + `message_id`, or `failed` + `error`); the queue retries with
+  exponential backoff (1s → 5min cap) and dead-letters the job when the attempts
+  run out, so a restart resumes delivery instead of losing it. The `'queued'`
+  status was already in `EmailDeliveryStatus` — no spec change.
+
+  Three ways to turn it on, all default-off:
+
+  - `new EmailServicePlugin({ queueDelivery: true })`
+  - `OS_EMAIL_QUEUE_ENABLED=true` (or `config.email.queueDelivery`) on `os serve`
+  - Settings → Mail → **Durable queue delivery**, hot-applied without a restart
+
+  **One retry budget, not two.** `retries` keeps its meaning — total attempts are
+  `retries + 1` in both modes. Inline it drives the in-process loop; queued it
+  becomes the queue's `maxAttempts` and the per-row loop is pinned to one attempt
+  per delivery. Turning the toggle on changes _where_ a retry happens (durable,
+  backed off) and never _how many_ happen, so the two layers cannot multiply.
+
+  **Fixed in the same change: the `email.send.async` subscriber inserted a new
+  `sys_email` row per delivery.** It called `send()` with the message, so a job
+  the queue retried five times left five rows — four permanently `failed`, none
+  carrying the real attempt count. It now delivers the referenced row via
+  `deliverPersistedRow`, so one message is one row and `attempt_count`
+  accumulates on it. Messages published in the old shape (a bare `SendEmailInput`)
+  are still accepted and delivered inline for a migration window.
+
+  Boundaries worth knowing before you switch it on:
+
+  - **"Send test email" always sends inline**, in every mode — the button has to
+    report the provider's own answer (`535 …`), and "queued" is exactly the
+    non-answer #5087 removed from it.
+  - **Messages with attachments or custom headers are delivered inline**, because
+    `sys_email` has no columns for them and a queued copy would arrive stripped.
+    Queueing them is tracked separately; this ships the loss-free behaviour.
+  - **A declaration that cannot be honoured fails the boot.** `queueDelivery: true`
+    from the constructor or `OS_EMAIL_QUEUE_ENABLED` with no durable queue
+    registered (or with `persist: false`) throws on `kernel:ready`, naming the
+    fix — the #5132 judgement, applied to durability. The **settings toggle** is
+    the opposite trade: it logs at `error` and keeps sending inline, because one
+    save must not stop the mail.
+  - The kernel's built-in in-memory `queue` fallback does **not** count as a
+    durable queue: it delivers synchronously with no retry or DLQ, so publishing
+    to it would report `queued` for a message nothing could ever recover. Mount
+    `@objectstack/service-queue` over an ObjectQL engine (the `queue` capability
+    does this on `os serve`) to get the `sys_job_queue`-backed adapter.
+
+  Leaving `queueDelivery` unset keeps today's behaviour byte for byte.
+
+- 02dc076: feat(types,cli,verify)!: 只解析 host app 声明过的包 —— `NODE_PATH` 不再算数,ADR-0093 D5 那道墙从此与启动方式无关 (#4719)
+
+  **问题:契约写下了,但从没被检查过。** `@objectstack/types/node` 的
+  `createHostRequire` 返回一个 CJS `createRequire`,而 CJS 解析认 `NODE_PATH`
+  (`Module.globalPaths`)。pnpm 生成的 bin shim 第一件事就是
+  `export NODE_PATH=<workspace>/node_modules/.pnpm/node_modules`,于是任何被工作区里
+  **任意一个包**传递依赖到的包都能"从 host app 解析成功" —— 跟这个 app 声明了什么毫无关系。
+
+  实测(cloud `apps/objectos-ee`,当时未声明 `@objectstack/organizations`):
+  `pnpm start`(经 shim)boot 成功、插件表里有 `Organizations`、ADR-0093 D5 一声不吭;
+  `node node_modules/@objectstack/cli/bin/run.js serve`(不经 shim)则
+  `✖ FATAL: tenancy posture 'isolated' was requested…` 并 exit 1。同一个 app、同一份
+  `package.json`、同一个 posture,**只因为进程是怎么被拉起来的**,走出两种结果。
+  而 D5 的报错一直在教 operator "declare it in the app's package.json" —— 那正是
+  CLI 从来没检查过的那件事。
+
+  **改法:声明即执行。** 解析前先读 `<hostRoot>/package.json`;只有包名出现在
+  `dependencies` / `devDependencies` / `optionalDependencies` / `peerDependencies`
+  的 **键**里,才去 host 的 `node_modules` 里查它。仅仅"能被解析到"不再算数 ——
+  那正是让契约失效的那个偶然。未声明的包退回到 importing package 自身的解析
+  (ESM,不认 `NODE_PATH`),框架自有的包加载路径不受影响。
+
+  **两种失败从此分开报。** 今天它们都塌成同一条 `MODULE_NOT_FOUND`,补救办法却相反:
+
+  - **未声明** —— 指向"在 app 的 `package.json` 里声明并安装",并说明为什么
+    hoisting / `NODE_PATH` 不被接受;
+  - **声明了但解析不到** —— 明确说这是**安装**问题(`pnpm install`、生产 prune
+    砍掉了它、dist 没构建),别再让人回去重看那份已经写对的 `package.json`。
+
+  分类经新导出的 `hostImportFailureKind(err)` 暴露给调用方;两种错误都仍带
+  `code: 'MODULE_NOT_FOUND'`,`isModuleNotFoundError` 的既有判定不变。
+
+  **BREAKING — 哪类部署会从假绿变红,以及怎么修。**
+
+  1. **靠 hoisting 苟着的部署。** 一个 app 请求了 walled tenancy posture
+     (`OS_TENANCY_POSTURE=group` / `isolated` 或 `OS_MULTI_ORG_ENABLED=1`)、
+     却没在自己的 `package.json` 里声明 `@objectstack/organizations`,过去经 pnpm
+     shim 启动能正常 boot —— 现在会命中 ADR-0093 D5 并 exit 1。
+     **修法:在那个 app 的 `package.json` 里声明该依赖并安装。**
+     这些部署本来就在未声明状态下运行,红的是一直存在的事实,不是新引入的故障:
+     同一个 app 不经 shim 启动今天就已经是 exit 1。
+     (同样适用于 `@objectstack/service-ai` / `@objectstack/service-ai-studio`,以及
+     `bootStack({ multiTenant: true })`、dogfood 的 enterprise 门。)
+
+  2. **`createHostImporter` 的签名变了**,因为它现在需要 host 的**根目录**才能读到
+     那份 manifest,而一个 `NodeRequire` 无法被问出它锚在哪里:
+
+     ```diff
+     - createHostImporter(createHostRequire(hostRoot))
+     + createHostImporter(hostRoot)                     // 省略参数 = process.cwd(),同旧默认
+     ```
+
+     `createHostRequire` 本身保持不变,仍然导出。
+
+  新增导出(`@objectstack/types/node`):`HOST_DECLARATION_FIELDS`、
+  `HostDeclarationField`、`HostDeclaration`、`readHostDeclaration`、
+  `isDeclaredByHost`、`packageNameFromSpecifier`、`HostImportFailureKind`、
+  `HOST_IMPORT_FAILURE_KIND`、`hostImportFailureKind`。
+
+- 123067c: fix(cli): the i18n walker collects `objects.<o>._sections` — section headings are gated and scaffolded like every other label (#5405)
+
+  An object's SECTION headings were the one declared, resolved, rendered
+  translation surface the shared i18n walker had no kind for.
+  `ExpectedEntry['source']` listed `object | field | option | view | action |
+globalAction | app | navigation | dashboard | widget | page` plus two
+  `metadataForm*` kinds — and those two cover **Studio metadata forms**
+  (`metadataForms.<type>.sections.*`, hidden behind `--include-platform`), not app
+  objects. So `objects.<o>._sections.<s>.label` was structurally unreachable in
+  both directions: `os i18n extract` never scaffolded a heading, and
+  `os lint` could not report one missing.
+
+  The surface itself was never in doubt. `ObjectTranslationDataSchema` declares
+  `_sections` (with `sections` as an authoring alias), and `@object-ui/i18n`'s
+  `sectionLabel` resolves it for `record:details`, for `ObjectForm`/`ModalForm`
+  and for the field-group designer. Only the walker disagreed — which is exactly
+  the drift `collectExpectedEntries` was consolidated to prevent (#3370).
+
+  Measured downstream before this landed: 85 sections across 15 objects, **2 of
+  85** translated in `ja-JP` and in `es-ES` — English headings on essentially
+  every record page and form — with `objectstack lint` reporting **zero** i18n
+  warnings for both locales.
+
+  **What is collected.** A `section` kind, from the two independent surfaces that
+  both resolve to the same key — a heading is expected if _either_ declares it,
+  and one heading is one expected key however many declare it:
+
+  - **`fieldGroups` × field `group`** — the fields decide which sections exist and
+    `fieldGroups[].label` supplies the source text. Membership is read through
+    `deriveFieldGroupLayout` (ADR-0085 §5), the same shared derivation the
+    renderers consume, so a group nothing visible references — or a `group:` no
+    `fieldGroups` entry declares — produces no heading and therefore no expected
+    key. The trailing ungrouped bucket renders without chrome and is skipped.
+  - **A named `sections[]`** on a form view (including a view container's default
+    `form`) or inside a record page's component tree.
+
+  A section with no `name` is skipped: every renderer guards the lookup on it
+  (`s?.name ? sectionLabel(…) : s?.label`), so it is untranslatable by
+  construction and demanding a bundle entry for it would be noise. A group that
+  declares no `label` still yields a scaffold key seeded from its own name, but no
+  coverage finding — nobody authored that text.
+
+  **What you get.** `os lint` gains an `i18n/missing-section` category — user
+  metadata, so it is reported without `--include-platform` — and `os i18n
+extract` scaffolds the headings for free, because the gate and the extractor
+  read the one walker. A project that declares no locales still reports nothing;
+  the gate stays opt-in.
+
+  **`@objectstack/lint`** now exports its shared page traversal
+  (`walkPageComponents`, `isSourceAuthoredPage`, `WalkedComponent`) so the CLI
+  consumes it instead of growing a private copy — that walk exists precisely
+  because duplicating it produced a dead rule once already (#3583). Reusing it is
+  also what makes the page half correct rather than merely present: it reaches
+  `slots.<slot>` and the untyped nesting a record page really uses
+  (`page:tabs` → `properties.items[].children[]` → `record:details`), skips
+  source-authored pages whose `regions` are a derived cache, and resolves each
+  component's OWN binding (`dataSource.object` → `properties.object` → the page's
+  `object`) — so a re-bound `record:details` keys its headings under the object it
+  actually shows.
+
+- b3c1f3c: i18n 提取器改用运行时视图身份来命名 `_views` 翻译键(#5164 第 1 棒 / cli 段)
+
+  **BREAKING(已发布翻译包的键):容器默认 `list` 的 `_views` 键由 `list` 改为运行时裸键。**
+
+  `objectstack i18n extract` / `os lint` 过去用 `view.list.name ?? 'list'` 推导一个
+  `defineView` 容器默认列表的翻译键,而运行时注册表(`expandViewContainer`,
+  `packages/spec/src/ui/view.zod.ts`)给同一个视图的身份是 `<object>.default`。两者是
+  两个不同的字符串,于是「只声明了默认 `list`、没有 `listViews`」的应用会拿到一份键为
+  `list` 的翻译骨架、一个键为 `default` 的运行时视图,界面上永远显示英文原文 —— 无论作者
+  按哪一侧编写都命中不了。
+
+  提取器现在**向组装器本身查询**这个键,而不是第二次自行推导。因此它同时继承了组装器
+  仅有的两条规则:
+
+  - 无 `name` 的默认列表键为 `default`(不再是 `list`);带 `name` 的沿用作者的 `name`;
+  - 结构上与某个 `listViews` 条目**完全相同**的默认列表会被组装器按签名折叠进该条目,
+    因此它没有自己的键 —— 提取器不再为它多写一个谁也读不到的骨架条目
+    (`examples/app-crm` 正是这个形状:`list` 与 `listViews.all` 同签名,真实键是 `all`)。
+
+  维护者 2026-08-06 裁决:`_views` 翻译键的 canonical 拼写 = 运行时身份的裸键。
+
+  ## 升级:翻译包键的 FROM → TO
+
+  只影响用 `defineView({ list: … })` 声明了**默认列表**、且为它写过翻译的包。
+
+  | 容器形状                                    | FROM                             | TO                                  |
+  | ------------------------------------------- | -------------------------------- | ----------------------------------- |
+  | 默认 `list`,无 `name`                       | `objects.<object>._views.list.*` | `objects.<object>._views.default.*` |
+  | 默认 `list`,带 `name: 'x'`                  | `objects.<object>._views.x.*`    | 不变                                |
+  | 默认 `list` 与某个 `listViews.<k>` 结构相同 | `objects.<object>._views.list.*` | 删除(`_views.<k>.*` 已经覆盖它)     |
+
+  一行修法:把 `_views.list` 改名为 `_views.default`;如果同一对象下已经有一个与默认列表
+  `type`/`label`/`columns` 完全一致的 `listViews` 条目,则直接删掉 `_views.list`。
+  重新跑一次 `objectstack i18n extract`(merge 模式保留已有译文)会得到正确的骨架。
+
+  本仓库自带示例已随迁:`examples/app-showcase` 5 个块、`examples/app-todo` 2 个语言包
+  改名为 `default`;`examples/app-crm` 3 个折叠形状的 `_views.list` 块删除。
+  `check:i18n-coverage` 棘轮基线经实测无需调整(需求侧与译文侧同批改名,覆盖数不变)。
+
+  `packages/lint` 的 `collectViewRecord` 收窄(#6038)与 objectui `viewSuffixes` 去第二
+  候选(objectui#3502)是本裁决的第 2、3 棒,不在本次变更内。
+
+### Patch Changes
+
+- b11a7e3: fix(cli): the boot banner's `Tenancy:` row now reports the resolved posture, not the superseded boolean (#4801)
+
+  `printServerReady` printed `Tenancy: multi-tenant | single-tenant` from a boolean
+  `multiTenant` that `serve` filled with `resolveMultiOrgEnabled()` — i.e. from
+  `OS_MULTI_ORG_ENABLED`. [ADR-0105 D1] replaced that knob with
+  `OS_TENANCY_POSTURE`, keeping the boolean only as the fallback
+  `resolveTenancyPosture()` consults when the posture is unset, and **the runtime
+  wiring in `serve` already keys off the posture**. So the banner and the server it
+  describes read two different sources for one fact, and they drifted exactly where
+  it hurts: booting with `OS_TENANCY_POSTURE=isolated` and `OS_MULTI_ORG_ENABLED`
+  unset printed
+
+  ```
+    Tenancy: single-tenant
+    Plugins: 40 loaded
+             …, Organizations, …
+  ```
+
+  — the banner claiming single-org one line above the plugin table that proves the
+  organization wall is up (observed on a real boot in cloud#1020, where the lie was
+  only caught by hand-comparing the plugin list).
+
+  This is not cosmetic. It is the "declared ≠ enforced" class (ADR-0049) landing on
+  the **diagnostic** surface, which is the worst place for it: a banner that can be
+  wrong costs every later investigation an extra lap proving whether it is.
+
+  **What changes for users.** The row now prints the posture verbatim — `Tenancy:
+single`, `Tenancy: group`, `Tenancy: isolated` — sourced from the same
+  `resolveTenancyPosture()` call the runtime wiring uses. The old `multi-tenant` /
+  `single-tenant` vocabulary is gone. That vocabulary was itself part of the defect:
+  tenancy has been a three-valued spectrum since ADR-0105, and a boolean has no
+  spelling for `group` at all, so a `group` deployment could only ever be
+  misreported.
+
+  **The internal `multiTenant` option is removed, not deprecated.** With the posture
+  authoritative, a retained boolean could only ever be a field the printer ignores —
+  and a field that exists but cannot be believed is precisely how this bug was
+  authored in the first place. `ServerReadyOptions.tenancyPosture` is typed as
+  `TenancyPosture`, so re-wiring the banner to the legacy boolean now fails to
+  compile (`resolveMultiOrgEnabled()` returns `boolean`) instead of producing a
+  plausible-looking wrong line. The interface is package-internal — `format.ts` is
+  not re-exported from `@objectstack/cli`'s entry point — so no consumer code needs
+  a change.
+
+  Regression-pinned in `packages/cli/src/utils/format.tenancy.test.ts`, which asserts
+  the printed token **is** `resolveTenancyPosture()`'s answer across the cases that
+  made the old code wrong: posture set with the boolean unset, posture unset with the
+  boolean true, both set and contradicting (either direction), the legacy `multi`
+  spelling, and `group`.
+
+- 3d94141: fix(cli): `os validate` / `os build` print the union branch's prescription, not a bare `invalid_union: Invalid input` (#5341)
+
+  Zod folds every branch of a failed `z.union` into ONE top-level issue whose own
+  `message` is the literal `"Invalid input"`; each branch's real rejection —
+  required-property and unknown-key prescriptions alike — sits in `issue.errors[]`
+  with paths relative to the union's own. The CLI's `formatZodErrors`
+  (`packages/cli/src/utils/format.ts`) walked only the top level, so an author who
+  mistyped a key inside a union member read:
+
+  ```
+    views:
+      ✗ views.0.list.sort
+        invalid_union: Invalid input
+  ```
+
+  …while the branch that names the key, and the fix, was produced on every run and
+  delivered on none. Three commands print through that one function — `os
+validate`, `os build` (compile) and `os plugin build` — so the terminal was the
+  one surface where the #4001 campaign's curated prose never arrived. It now
+  reads:
+
+  ```
+    views:
+      ✗ views.0.list.sort
+        invalid_union: Invalid input
+          ✗ views.0.list.sort.0.order: Invalid option: expected one of "asc"|"desc"
+          ✗ views.0.list.sort.0: Unrecognized key(s) on this sort entry: `direction`. … Did you mean `direction` → `order`?
+  ```
+
+  This is the same defect's **third** consumer, and it reuses the branch-selection
+  policy the first two landed rather than re-deriving it: drop branches that only
+  say "wrong kind of value", prefer the branch complaining least so one stray key
+  is not reported once per branch (the #4001 批 6c regression), break ties on
+  `unrecognized_keys`, absolute paths, bounded expansion depth. `formatZodError`
+  (spec, #4971) and `zodIssuesToFields` (the REST wire, #5014) already carry it;
+  because the terminal needs exactly the string spec already exports, this one is
+  a plain `formatZodIssue` import instead of a third copy — so one mistake cannot
+  get three different prescriptions depending on which surface the author hit.
+
+  Strictly additive: the union's own `✗ path` / `invalid_union: Invalid input`
+  lines still print, non-union issues render byte-for-byte as before, and the
+  `N validation error(s) total` footer still counts `error.issues` — one union is
+  one issue however many lines explain it, which keeps the footer agreeing with
+  the `--json` payload beside it. The `--json` path is untouched; it passes
+  `error.issues` through and always carried the whole tree.
+
+- 0b720de: CLI: load the SQL driver's schema-work classifier lazily, so an unbuilt driver no longer breaks command discovery (#5726)
+
+  `packages/cli/src/utils/schema-migrate.ts` statically value-imported
+  `isInPlaceSchemaWork` from `@objectstack/driver-sql`. oclif's `findCommand`
+  `import()`s every command module on every CLI invocation, and nine commands
+  reach that file (`meta:resync`, `migrate`, and seven `migrate:*`), so a
+  workspace whose `packages/drivers/driver-sql/dist` was not built printed nine
+  `MODULE_NOT_FOUND` blocks — naming nine commands the operator never invoked —
+  in front of whatever command they actually ran, and dropped all nine out of the
+  command table (`os migrate plan` answered `Command migrate:plan not found.`).
+
+  The import is now `await import('@objectstack/driver-sql')` at the point of use,
+  inside the two renderers that need the classifier. The classifier keeps its one
+  definition in the driver — it is a fact about `PendingSchemaWorkKind` and a copy
+  in the CLI could disagree, listing a row rewrite under the heading that promises
+  the work is never data-losing.
+
+  No user-visible behaviour change: this is local/worktree developer experience
+  only, and CI always builds before running the CLI. `renderPendingSchemaWork` and
+  `summarizePendingSchemaWork` — internal helpers, not part of the package's
+  public entry — are now `async`.
+
+- aa25a81: fix(client)!: `DeleteDataResult` declares the schema it names — `success`, not `deleted` (#5638)
+
+  `DeleteDataResult` — the return type of `client.data.delete()` and of the
+  project-scoped `client.project(id).data.delete()` — carried the comment
+  `Spec: DeleteDataResponseSchema` above a declaration that contradicted it:
+
+  ```ts
+  /** Spec: DeleteDataResponseSchema */
+  export interface DeleteDataResult {
+    object: string;
+    id: string;
+    deleted: boolean; // ← the schema declares `success`
+  }
+  ```
+
+  `DeleteDataResponseSchema` (`packages/spec/src/api/protocol.zod.ts`) declares
+  `{ object, id, success }`. `deleted` has never been declared by any schema, and
+  no server path has ever returned it on `/data/:object/:id`.
+
+  **The old key was never readable at runtime — this rename reveals a defect, it
+  does not break working code.** Both `delete` surfaces are pure `unwrapResponse`
+  / `_unwrap` passthroughs: the SDK returns the server's body untouched, so this
+  interface is a _claim_ about the wire, never a rewrite of it. The claim was
+  false in the one direction that matters — the compiler endorsed the wrong
+  spelling:
+
+  ```ts
+  const r = await client.data.delete('task', id);
+  if (r.deleted) { … }   // compiled; `undefined` at runtime; branch never taken
+  if (r.success) { … }   // rejected by the compiler; correct on the wire
+  ```
+
+  ## What to change
+
+  `r.deleted` → `r.success`. That is the whole migration. Nothing about the
+  request, the route, the status codes or the error shapes changes, and no server
+  needs upgrading: the value you are now allowed to read is the one that was
+  already arriving.
+
+  ⛔ **Do not write `r.success ?? r.deleted`.** There is one producer shape, and a
+  consumer that accepts two spellings is the shape contract-first exists to
+  prevent — the same ruling #5581 applied on the producer side. No deprecated
+  `deleted?: boolean` transition key ships for the same reason; a transition
+  period is for keys that _worked_, and this one never did.
+
+  ## Why the type was wrong on every deployment, not just some
+
+  The protocol path (`deleteData`) has always answered `success`. #5581 / PR
+  #5641 brought the ObjectQL fallback — the path a slim assembly without
+  `MetadataPlugin` takes — to the same shape. So before that fix the declaration
+  was wrong on ordinary deployments and accidentally right on slim ones; after
+  it, both paths answer `{ object, id, success }` and the declaration was simply
+  wrong everywhere. The consumer-side correction had to follow the producer, not
+  lead it.
+
+  ## `os data delete` was reading the phantom key too
+
+  `packages/cli/src/commands/data/delete.ts` built its `--format json` / `--format
+yaml` payload with `deleted: result.deleted`. That evaluated to `undefined`, and
+  `JSON.stringify` drops undefined values — so the `deleted` key the command has
+  always declared **never appeared in a single run**. It now carries
+  `result.success`, the server's own verdict.
+
+  Observable change: `os data delete --format json` gains `deleted: true` (YAML
+  likewise) on a successful delete. The key name stays `deleted` deliberately —
+  it is the CLI's output key, not the protocol's, and the payload's top-level
+  `success` already means something different (the CLI envelope's "the command
+  completed"). Conflating the two is the hazard #5641 called out when it noted
+  that `body.success` and `body.data.success` are different facts. Scripts
+  reading `.deleted` from this command were reading `undefined` before and get a
+  boolean now; nothing that worked stops working.
+
+  ## Downstream
+
+  `objectui`'s `ObjectStackDataSource.delete()` is a live victim of the old
+  declaration — it guards `emitMutation` on `result.deleted`, so the delete
+  mutation event has never fired against a real server and the method returns
+  `undefined` where it declares `boolean`. Its own suite stayed green because the
+  fixture mocks `{ deleted: true }`, a body no server produces. Filed as
+  objectstack-ai/objectui#3412, which is blocked on this package publishing —
+  its fix is a type unblock, not a behaviour change, since `success` is already
+  what arrives.
+
+  ## Pins
+
+  `packages/client/src/data-delete-result-shape.test.ts` asserts mutual
+  assignability between `DeleteDataResult` and the spec's `DeleteDataResponse`,
+  so a rename on either side (or a re-added optional `deleted`) fails
+  `check:test-typecheck`. `client.hono.test.ts` gains the delete case this live
+  server suite never had: a real DELETE over HTTP whose body is read as
+  `deleted.success` and whose key set is asserted literally — `z.object` strips
+  unknown keys, so a passing parse alone cannot prove no stray `deleted` rode
+  along.
+
+- 9c4a14c: `os dev --fresh` states the isolation it actually delivers (#5594)
+
+  The `--fresh` block promised its tempdir "owns ALL persistent state for this
+  run". After #4968 that is true of everything the CLI itself places — the dev
+  SQLite DB (`OS_HOME` → `<home>/data/dev.db`, published as `OS_DATABASE_URL`),
+  the uploads root (published on the settings service's own name
+  `OS_STORAGE_LOCAL_ROOT`), and any plugin state keyed off `OS_HOME` — but it was
+  never true of state an **app** reaches by a relative path it declares itself.
+  Such a path is resolved by its own consumer against the process working
+  directory, which `--fresh` does not move, so the file lands in the project tree
+  and is still there after the run exits.
+
+  The live specimen is deliberate authoring, not a bug: the showcase's
+  `showcase-external` datasource declares
+  `filename: '.objectstack/data/showcase_external.db'` and documents that the path
+  resolves against the project cwd — so a `--fresh` showcase run leaves that file
+  (plus `-wal`/`-shm`) behind.
+
+  No behaviour changed. The `--fresh` flag help, the source comments, and the
+  `os dev` flag table in the CLI docs now name the covered surface
+  (`OS_HOME`-keyed state plus the env channels the CLI publishes) and state
+  plainly what falls outside it, with a docs note on declaring an absolute path
+  when a datasource should follow `--fresh`.
+
+  Re-anchoring app-declared relative paths on `OS_HOME` is a behaviour change
+  resting on an open contract question ("relative to cwd" vs "relative to this
+  run's home") and is deliberately not taken here.
+
+- 36fc938: fix(cli): `objectstack dev` restarts the server after each rebuild — the running server can no longer silently disagree with `dist/objectstack.json` (#5148)
+
+  The dev watcher rebuilt `dist/objectstack.json` on every source change and
+  printed `✓ recompiled — server will auto-reload`, but the running serve child
+  only **partially** received the rebuilt artifact: MetadataPlugin's own
+  artifact watcher re-ingests the metadata registry, syncs DDL + seeds for
+  newly-appearing objects and broadcasts the SSE HMR event — while hook bodies
+  and already-registered view metadata from the compiled bundle are applied at
+  **boot only**. #5148 measured both staying stale: the old hook kept executing
+  and `/api/v1/meta/views` kept serving the old view after a confirmed on-disk
+  rebuild, with no error and no warning. That made every dev edit/verify loop
+  capable of a false conclusion in either direction ("my fix doesn't work" /
+  "this code isn't load-bearing").
+
+  `objectstack dev` now supervises its serve child nodemon-style:
+
+  - **Auto-restart (default-on).** After a rebuild lands on disk, the serve
+    child is SIGTERMed (the kernel shuts down gracefully), and a replacement is
+    spawned once it exits — boot-time load is the one path that applies the
+    whole artifact. Restarts coalesce (rapid saves produce one restart), a
+    child that ignores SIGTERM is force-killed after 8s, a replacement that
+    fails to come up is loud and exits dev, and parent SIGINT/SIGTERM is
+    forwarded to the child so no orphan server outlives dev.
+  - **`--no-restart` opt-out.** The watcher then only rebuilds the artifact —
+    and every rebuild now says explicitly that the running server keeps the
+    build it booted with. The watch banner states the active mode instead of
+    implying a hot reload the runtime only partially performs.
+  - **Boot-time staleness warning (#5148 startup variant).** When
+    `objectstack.config.ts` / `src/**` are newer than the artifact at boot
+    (edited while the server was down), dev warns loudly that the boot serves
+    the stale build, names the newest source file and the remedy
+    (`objectstack build`, `--compile`, or save a watched file). The boot is
+    never gated — the silence is removed, not the start.
+
+- 235b94a: fix(cli): `os doctor` 按 `os serve` 的环境载入 `objectstack.config.ts`(#5397)
+
+  #5387 让 doctor **读**到了 `os serve` 的那份 `.env*` cascade,但 overlay 只套在一处读取上:
+  env 派生检查(posture,以及以它为闸门的 ADR-0120 D5e 建议)。`loadConfig()` 留在了外面。
+  于是两条命令仍然在**两份不同的环境**下打包同一个配置文件:
+
+  ```
+  # .env
+  OS_DATABASE_URL=postgres://…
+
+  # objectstack.config.ts —— 顶层读环境变量是常见写法,不是刁钻写法
+  const url = process.env.OS_DATABASE_URL;
+  if (!url) throw new Error('OS_DATABASE_URL is required');
+
+  $ os serve    # dotenvFlow.config()(serve.ts:520)→ 之后才 bundleRequire → 正常启动
+  $ os doctor   # 无 overlay 直接 bundleRequire → 抛错 → 被 config 分析那个很宽的 try 吞掉
+                # → 「⚠ Could not load config for analysis (config checks skipped)」,warning,exit 0
+  ```
+
+  两种危害,安静的那种更糟:
+
+  1. **响的** —— 上面那句话把责任推给配置文件,而配置文件没问题,同一个目录 `os serve`
+     正常启动。它正是 #5382 判定为「归因错误」的那句,残存在 #5387 刻意没动的这条路径上。
+  2. **哑的** —— 配置文件只要**按环境值分支**(条件声明的 object / datasource),它对 doctor
+     和对服务器就声明了不同的形状,于是下面每一项检查(循环依赖、未引用对象、孤儿视图、
+     仪表盘完整性、spec 版本)判定的都是一份**服务器不会运行**的配置。全程不打印任何东西。
+     这一半没有任何 warning 会浮现出来。
+
+  **现在的行为。** `loadConfig()` 套上 `run()` 顶部已经解析好的**同一份** `dotenvReading`
+  (不是第二次 `readDotenvFiles()` —— 一轮 doctor 只解析一次 cascade,否则 `Environment files`
+  那一行就未必是 config 载入真正看到的那份)。
+
+  `withDotenvOverlayAsync` 而不是既有的同步版:配置文件的顶层跑在 `bundleRequire` 的动态
+  `import()` 里面,同步版的 `finally` 会在 `loadConfig()` 交回 pending promise 的那一刻就把
+  overlay 摘掉 —— 套上了,又在被读之前摘掉,等于没套。两者共用同一套 apply/revert
+  (dotenv-flow 自己 `unload()` 的判定:只删掉仍然等于写入值的那些),不是抄一份。
+
+  **判定面的变化是本单的修复内容,不是副作用**(与 #5398 对 D5e 建议的处理同一姿态)。
+  可观察的差异有三类,都如实呈现:
+
+  - 此前因缺值抛错而被跳过的配置,现在**载入成功**,那句归因错误的 warning 不再出现,而
+    下面那一整组 config 检查**开始运行** —— 因此可能新增此前从未打印过的 warning
+    (真机复现:`⚠ Object "account" is defined but not referenced by any view, flow, app, or lookup field`,
+    在修复前整块被跳过,一条都看不到);
+  - 按环境值分支的配置,doctor 判定的对象/视图集合改为与 `os serve` 一致;
+  - 配置**确实**坏掉时,`Could not load config for analysis (config checks skipped)`
+    **照旧触发**。套上 cascade 之后仍然载入不了的配置,`os serve` 同样载入不了 —— 这句话
+    从此归因正确,而不是被消音。把它一并静默,等于用「没有 warning」换掉「归因错误的
+    warning」。
+
+  **来源口径不变:只报来源,从不报值。** 这一点在本次改动后更吃重:overlay 现在携带的是
+  配置文件想读的**任意**变量,而不再是 `DOCTOR_ENV_INPUTS` 这个声明过的子集,而 `.env` 正是
+  密钥的常见住处。变量名无法预先枚举,提供它们的**文件**可以 —— `Environment files` 仍是
+  报告 cascade 的唯一一处,并在其中说明这些文件同样施加于配置载入:
+
+  ```
+        These files are also applied while objectstack.config.ts is loaded, so a config
+        that reads process.env at top level sees the values `os serve` gives it.
+  ```
+
+  overlay 的边界也照旧:它在配置文件**载入**期间有效,而不是常驻整轮运行 —— doctor 分析的
+  一切都是模块求值时读出的普通值,载入结束即摘除(回调抛出时同样摘除,有测试钉住)。
+
+- 533d73f: fix(cli): `os doctor` 说出配置载入失败的**原因**,不再只说一句「载入不了」(#5403)
+
+  config 分析那个很宽的 `catch` **不带绑定**(`catch {`),error 对象在被捕获的那一刻当场丢弃。
+  于是配置真坏掉时,报告里没有任何线索:
+
+  ```
+  $ cat objectstack.config.ts
+  throw new Error('this config is genuinely broken');
+
+  $ os doctor
+    → Loading configuration for analysis...
+    ⚠ Could not load config for analysis (config checks skipped)
+
+  ⚠️  Environment is functional but has some warnings.
+  ```
+
+  `this config is genuinely broken` 一个字都不出现,`--verbose` 也没有 —— 这句话是裸
+  `printWarning` 直接打的,不是 `HealthCheckResult`,所以根本没有 `fix` 可供展开,没有任何
+  旗标能让操作者看到更多。而 `os serve` 在同一个目录会把这个错误**完整**打出来。诊断命令在
+  它最该出力的一刻(配置坏了),给出的信息**严格少于**直接跑 `os serve`。
+
+  这与前三单是同一句话的不同侧面:#5382 / #5387 / #5397 修的是这句话的**归因**(先把
+  posture 的抛错挪出这个 catch,再让 env 派生检查读到 serve 的环境,最后让配置载入也在
+  serve 的环境下进行)。三单之后这句话触发时配置**确实**坏了。本单修的是它归因正确之后
+  **说了什么**。
+
+  **现在的行为。** 这条路径不再是裸 `printWarning`,而是一条常规 `HealthCheckResult`,与
+  `Environment files` / `Tenancy posture` 走**同一个渲染器**、同一条 `--verbose` 展开规则:
+
+  ```
+  $ os doctor
+    → Loading configuration for analysis...
+    ⚠ Config load          Could not load config for analysis (config checks skipped) — this config is genuinely broken
+
+  $ os doctor --verbose
+    ⚠ Config load          Could not load config for analysis (config checks skipped) — this config is genuinely broken
+        → `os serve` loads this same file the same way — bundle-require, under the `.env*`
+          cascade named above (#5397) — and prints this error in full, so a config that
+          lands here is one the server cannot boot either.
+          The config-aware checks were SKIPPED, not passed: spec version, circular
+          dependencies, unused objects, orphan views, dashboard integrity.
+          cause: this config is genuinely broken
+  ```
+
+  四条刻意的取舍:
+
+  - **原话照引,不改写。** 与 #5390 引 `resolveTenancyPosture()` 原话同一体例:抛错方拥有措辞。
+    配置载入的失败可能来自四个不同的权威(用户自己的 `throw`、esbuild 的打包诊断、Node 的
+    模块解析、`loadConfig()` 自己的 "no default export"),doctor 没有立场把它们总结得比它们
+    自己更好。
+  - **cause 进 `message`,而不只进 `fix`。** `Environment files` 把 cause 只放在 `fix` 里是对的
+    —— 那一行本身已经把结论说完整了,cause 是脚注。这里 cause **就是**结论:没有它,这一行
+    只说了「出了点没被指名的问题」。所以平铺一行放收敛后的引文(多行折叠成一行、超长截断),
+    `--verbose` 给未截断的原文。折叠而不是取首行,是因为 esbuild 的首行恰好是它最没信息量的
+    一句(`Build failed with 1 error:`,文件与原因在下一行)。
+  - **档位不变。** 仍是 warning,doctor 仍然跑完其余检查,仍然 exit 0。本单让这句话说得更多,
+    不是说得更响。
+  - **那句话本身原样保留**,作为该行的开头。它被两份 changeset 引用、被本文件四处注释引用,
+    也是操作者会去 grep 的字符串;更要紧的是,兄弟测试用它的**缺席**来表示「配置载入成功」,
+    改写它会让那些断言在「没有任何东西能匹配」的空理由下继续变绿。
+
+  顺带消掉的是一条旁路:渲染规则此前只存在于环境检查那个 `forEach` 的循环体里,任何在它之后
+  产生的结论都只能自己再手打一遍格式 —— 而手打的那份没有 `fix` 通道,`--verbose` 对它无效。
+  渲染规则现在是一个具名函数,两处共用。
+
+- 98369a8: fix(cli): `os doctor` 按 `os serve` 的顺序读 `.env*`,并逐值注明来源(#5387)
+
+  `serve` / `dev` / `start` 三条命令都在读第一个 `OS_*` 变量之前用 dotenv-flow 载入
+  `.env*`(`serve.ts:520`、`dev.ts`、`start.ts`);`doctor` **一个都不载入** ——
+  `grep -n dotenv packages/cli/src/commands/doctor.ts` 此前只匹配到一句「我不载入」的注释。
+  于是被诊断的环境和诊断者看到的环境,不是同一个环境:
+
+  ```
+  # .env,提交进仓库、团队共享
+  OS_TENANCY_POSTURE=isolatd
+
+  $ os doctor      # 看不到 .env,posture 解析成 single,报绿,exit 0
+  $ os serve       # 载入 .env,读到 isolatd,FATAL 拒绝启动(PR #5381 的闸门)
+  ```
+
+  `.env` 恰恰是这个变量最常见的来源 —— PR #5381 把 serve 的闸门刻意放在 dotenv 载入
+  **之后**,理由正是这个。在 #5382 之前 doctor 没有任何 env 派生检查,这条不一致不产生
+  可观察差异;#5382 加了第一项(posture),它才有了落点,也才成为「诊断面与运行时不一致」
+  (#4801 / cloud#1020 家族)在 `.env` 这条来源上的残留。
+
+  **现在的行为。** doctor 用 dotenv-flow 自己的 `listFiles()` 取到 `os serve` 会载入的
+  同一份文件清单(`node_env` 按 serve 同款推导:`NODE_ENV || production`;doctor 没有
+  `--dev`,serve 表达式里的 `'test'` 分支在 `flags.dev` 为假时是恒等的),逐个文件解析,
+  让每个变量记住它是在**哪个文件**里胜出的。两条约束是这次改动的实质:
+
+  - **不静默合并进 `process.env`。** 文件里的值只在需要它的那一次读取周围套上(
+    `withDotenvOverlay`),`finally` 里再摘掉 —— 用的是 dotenv-flow 自己 `unload()` 的判定
+    (只删掉仍然等于写入值的那些),所以回调故意改写的值不会被误删。运行中后续的一切
+    (config 打包、外部命令)不会莫名其妙继承一个跟昨天不一样的环境。
+  - **逐值注明来源。** 报告新增一行常驻体检项,说明载入了哪些文件、以及每个 env 输入来自
+    shell 还是哪个文件:
+
+  ```
+    ✓ Environment files    .env, .env.production (node_env=production), the cascade `os serve` loads — OS_TENANCY_POSTURE from .env.production, OS_MULTI_ORG_ENABLED from .env
+  ```
+
+  只静默合并、不注明来源,只是把盲区从「doctor 没读我的 `.env`」平移成「doctor 到底信了我
+  四个 `.env*` 里的哪一个」—— 同一类缺陷往前挪一层。该行**只报来源、从不报值**,所以
+  `DOCTOR_ENV_INPUTS` 将来加入带密钥的变量也不会因此泄露(唯一被打印的值是**非法**的
+  `OS_TENANCY_POSTURE`,由 posture 那条 finding 原样引回给作者看自己的拼写)。
+
+  **posture 那条 finding 的文案随之改写。** #5382 写的是「unlike `os serve`, `os doctor`
+  does not load `.env*` files」—— 在当时如实,也正是 #5387 被开出来的原因。现在同一个位置
+  说的是它**读到了什么**:
+
+  ```
+        Read from .env.production — `os doctor` loaded the same `.env*` cascade
+        `os serve` does (node_env=production: .env, .env.production).
+  ```
+
+  优先级与 serve 一致:shell 里已存在的变量胜过所有文件(dotenv-flow 用 `hasOwnProperty`
+  判定,所以 shell 里显式写空 `OS_TENANCY_POSTURE=` 也胜过 `.env` 里的值),cascade 里靠后
+  的文件胜过靠前的。
+
+  **一个如实说明的影响面:** 本改动改变的是 doctor **每一项 env 派生检查**的输入。今天落在
+  两处 —— posture 报告,以及 ADR-0120 D5e 的 unique-scope 建议(它只在 posture 为
+  `isolated` 时运行,所以一个只写在 `.env` 里的 `isolated` 现在会让它在 doctor 里跑起来,
+  和 `os serve` 一致)。这正是本单要修的东西,不是副作用。用户配置文件(
+  `objectstack.config.ts`)自身读 `process.env` 的那条路径**没有**套上 overlay,以免改变既有
+  config 检查的判定,另行记录。
+
+- 9fad07f: fix(cli): `os doctor` no longer prints `✓ Unique scope` when it could not read the installed-package ledger (#5412)
+
+  `readInstalledPackageEntries()` wrapped two unrelated facts in one un-bound
+  `catch` and returned an empty entry list for both:
+
+  - **`@objectstack/cloud-connection` does not resolve** — the optional package is
+    not installed. Silence is correct here and stays: `os doctor` must run to
+    completion in a checkout that never had it.
+  - **The ledger directory exists and could not be read** — `fs.existsSync()` had
+    already confirmed the directory is there, and producing its entry list threw
+    (the path is occupied by a file, the filesystem refused, the read failed).
+
+  The second was handled as the first. It reached the ADR-0120 D5e unique-scope
+  advisory as "no installed packages", the advisory found nothing to report, and
+  the run printed:
+
+  ```
+    ✓ Unique scope          No unconfirmed installation-wide uniques for this 'isolated' environment
+  ```
+
+  So an environment **with** installed packages, whose ledger doctor could not
+  read, got a clean bill of health for the one constraint the `isolated` posture
+  makes dangerous. That is worse than a missing check: a false PASS is what stops
+  an operator looking further.
+
+  The two are now separate. The `import()` failure keeps its own silent `catch`;
+  a ledger read failure comes back as a cause the caller can report, and the
+  success line is withheld — it is a claim about **both** halves of the advisory
+  (this project's metadata, and the manifests of installed packages), so it may
+  only be printed when both halves ran. In its place doctor prints an ordinary
+  `HealthCheckResult` through the same renderer every other check uses:
+
+  ```
+    ⚠ Unique scope          Could not read the installed-package ledger (installed packages NOT
+                            checked for installation-wide uniques) — ENOTDIR: not a directory, …
+  ```
+
+  **Warning, not error**, and the exit code is unchanged: the environment still
+  runs; what broke is doctor's ability to see part of it. The cause is quoted from
+  the thrower rather than paraphrased, and `--verbose` expands the untruncated
+  original plus which half of the check did not run — both free from reusing
+  `renderHealthCheckResult()`.
+
+  Findings from the half that **did** run are still reported: a ledger failure
+  does not swallow the uniques this project's own metadata declares.
+
+  **Not covered by this change**: a single _corrupt entry_ inside an otherwise
+  readable ledger. `LocalManifestSource.list()` skips unparseable files in its own
+  per-file `catch`, so a truncated manifest is dropped inside the producer and the
+  call succeeds with a short list that no consumer can distinguish from a complete
+  one. Fixing that is a change to `@objectstack/cloud-connection`'s own contract
+  and is tracked separately; the boundary is pinned by a test so it is not
+  mistaken for covered.
+
+- 214f67c: fix(cli): `os doctor` no longer treats a broken `@objectstack/cloud-connection` install as "not installed" (#5644)
+
+  `readInstalledPackageEntries()` reached the installed-package ledger through a
+  dynamic `import('@objectstack/cloud-connection')` whose `catch` meant "the
+  optional package is not installed". That is right for one of the two things it
+  caught:
+
+  - **The specifier does not resolve** — the optional package really is not
+    there. Silence is correct and unchanged: `os doctor` must run to completion in
+    a checkout that never had it.
+  - **The package is installed and will not load** — a pruned or unbuilt `dist/`,
+    an interrupted install, an artefact that throws while it evaluates, a
+    transitive dependency missing under it. It threw too, so it was answered with
+    the same silence.
+
+  The ADR-0120 D5e unique-scope advisory then saw "no installed packages", found
+  nothing to report, and the run printed:
+
+  ```
+    ✓ Unique scope          No unconfirmed installation-wide uniques for this 'isolated' environment
+  ```
+
+  Measured: with the package present-but-unloadable and a ledger declaring an
+  installation-wide `unique`, that line was printed and the finding appeared
+  nowhere, `--verbose` included. It is the same false PASS #5412 removed at the
+  `readdir` boundary and #5413 at the entry boundary, one boundary further up —
+  and `os serve`, loading the same package in the same directory, has always named
+  the failure out loud.
+
+  The two states are now separated by **resolution**, not by the `import()` having
+  thrown (`isModuleNotFoundError()` first — an error that is not a module-not-found
+  error came from the package itself, so it is present by definition; then
+  `import.meta.resolve()`, which answers "is the package there" without stating its
+  entry file, unlike `createRequire().resolve()`). Only the genuinely-absent half
+  is silent. The other prints an ordinary `HealthCheckResult` through the same
+  renderer every other check uses:
+
+  ```
+    ⚠ Unique scope          Could not load the installed-package ledger reader (installed packages
+                            NOT checked for installation-wide uniques) — Cannot find module …
+  ```
+
+  **Warning, not error**, and the exit code is unchanged, matching its two
+  siblings: the environment still runs; what broke is doctor's ability to see part
+  of it. The cause is quoted from the thrower, and `--verbose` expands it together
+  with the remedy — reinstall, or build the package in a monorepo checkout.
+
+  The row is **not** conditional on `.objectstack/installed-packages/` existing.
+  Doctor cannot honestly say a ledger is absent when the constant naming the
+  ledger's location is an export of the package that would not load.
+
+  One consequence worth stating: in a monorepo checkout where
+  `packages/cloud-connection` has not been built, `os doctor` under the `isolated`
+  posture now prints this warning instead of a clean bill. That state is exactly
+  what sent #5612 chasing a report face that had never regressed.
+
+- ccba1bb: fix(cli): `os doctor` 指名道姓报告非法 `OS_TENANCY_POSTURE` 并以非零码退出,不再报成一句「Could not load config」(#5382)
+
+  `resolveTenancyPosture()`(`@objectstack/types`)对无法识别的值抛错。doctor 有两处读
+  posture —— ADR-0120 D5e 的 unique-scope 闸门,以及 `findUnscopedGlobalUniques()` ——
+  **两处都在 config 分析那个很宽的 `try` 里**,而它的 catch 只会打印
+
+  ```
+    ⚠ Could not load config for analysis (config checks skipped)
+  ```
+
+  并记一个 warning。于是一个 `os serve` 会**拒绝启动**的环境,`os doctor` 报成:
+
+  ```
+  ⚠️  Environment is functional but has some warnings.     EXIT=0
+  ```
+
+  全程不出现 `OS_TENANCY_POSTURE` 这个词。一行里两个缺陷:**归因错了**(配置本身没问题,
+  被指着的是配置),**严重级也错了**(exit 0 意味着任何把 `os doctor` 放进 CI/健康检查的
+  地方,都不会因为这个「环境根本起不来」的配置错误变红)。这正是 #4801 / cloud#1020 那类
+  「诊断面与运行时不一致」,而且落在最糟的位置 —— `os doctor` 就是运维在 `serve` 起不来
+  之后会去跑的那条命令。
+
+  **现在的行为。** posture 在 `run()` 顶部、**任何 `try` 之外**解析一次。非法值产出一条
+  普通的 `error` 体检项:
+
+  ```
+    ✗ Tenancy posture      OS_TENANCY_POSTURE="isolatd" is not a recognized tenancy posture — `os serve` refuses to boot this environment
+        → Set one of the accepted values:
+          • OS_TENANCY_POSTURE=single — one organization, no organization wall — the default
+          • OS_TENANCY_POSTURE=group — organization wall enforced by the open engine, one shared database
+          • OS_TENANCY_POSTURE=isolated — organization wall + the enterprise @objectstack/organizations runtime …
+          • or unset OS_TENANCY_POSTURE entirely — the posture then derives from
+            OS_MULTI_ORG_ENABLED (true ⇒ isolated, anything else ⇒ single)
+        Read from this process's environment only: unlike `os serve`, `os doctor` does not
+        load `.env*` files, so a value set in one is not visible here.
+        cause: Invalid OS_TENANCY_POSTURE="isolatd". …
+  ```
+
+  修法清单由 `@objectstack/spec/security` 的 `TENANCY_POSTURES` 生成,不是第二份字面量,
+  新增一个 posture 不会让这段建议悄悄过期;`cause` 直接引用解析器自己的那句话,doctor 不
+  维护会跟它跑偏的第二份措辞。
+
+  **与 #5359 / PR #5381 给 `serve` 加的闸门同形,但裁决不同,且是刻意的**:serve 是**拒绝**
+  (FATAL + 在任何启动动作之前 `process.exit(1)`),doctor 是**报告** —— 报告照常跑完,由
+  doctor 自己的错误汇总给出非零退出码。doctor 的语义是「把所有问题一次说清」,不是「停下」。
+
+  两处读 posture 的地方现在复用同一个已解析值,不再各自重新解析。
+
+  **顺带修好的一个更大的洞:** 那两处读取此前都在 `if (configExists())` 之内 —— 一个没有
+  `objectstack.config.ts` 的环境**从来没读过** posture,连那句归因错误的 warning 都不会有。
+  现在与是否存在配置文件无关。
+
+  **一个如实说明的残留:** `os doctor` 不加载 `.env*`(`serve`/`dev`/`start` 用 dotenv-flow
+  加载),所以写在提交进仓库的 `.env` 里的非法 posture 仍然到得了服务器、到不了这份报告。
+  文案里明说了这一点,不冒充自己检查过 —— 该跨命令不一致另行记录为 #5387。
+
+- cd2efe6: `config.email.persist` now actually reaches the email plugin (#5447)
+
+  `EmailServiceConfigSchema` has always declared `persist` — the generated
+  reference documents it as "Persist to sys_email (default true)" — and
+  `EmailServicePlugin` has always honoured the constructor option, building no
+  `EmailPersistence` when `persist === false`. What did not exist was the segment
+  between them: `resolveEmailCapabilityArg` in `os serve` is the only reader
+  `config.email` has, and it read every declared key except this one.
+
+  So a deployment that wrote `email: { persist: false }` to keep message bodies
+  out of the database type-checked, parsed, and read as configured — and went on
+  writing every subject, body and recipient to `sys_email`. Operators who
+  switched persistence off for PII reasons were not getting what the contract
+  promised. **If you rely on that row being written, no action is needed; if you
+  had declared `persist: false` and audited on the assumption it took effect,
+  those rows exist and are worth reviewing.**
+
+  Resolution order, per setting, matching the rest of this resolver:
+
+      OS_EMAIL_PERSIST_ENABLED  >  config.email.persist  >  default (persist ON)
+
+  `OS_EMAIL_PERSIST_ENABLED` is new, and reads the same truth table as
+  `OS_EMAIL_QUEUE_ENABLED` (`1`/`true`/`yes`/`on`, case- and space-insensitive);
+  that table is now one shared helper instead of two copies. Unlike the queue
+  flag it is default-ON, because it does not enable a capability — it is the off
+  switch for one that has always been on. A deployment that declares neither
+  source is byte-for-byte unchanged: the key is left out of the plugin's
+  constructor options entirely and the plugin's own default decides.
+
+- 736519d: fix(cli): `OS_APP_NAME` overrides `config.email.defaultTemplateContext.appName` again (#5448)
+
+  `resolveEmailCapabilityArg` computed the email template context's `appName`
+  first and then spread the whole `config.email.defaultTemplateContext` over it.
+  A config that spelled `defaultTemplateContext: { appName: 'Acme Dev' }`
+  therefore made `OS_APP_NAME` inert — silently, with nothing logged — even
+  though this resolver's stated contract ("`OS_EMAIL_*` environment variables
+  override per setting", the header of `EmailServiceConfigSchema` and of the
+  generated `references/system/email-config` page) holds for every other key it
+  reads: `apiKey`, `defaultFrom`, `retries`, `queueDelivery`, `persist`, SMTP.
+
+  One `objectstack.config.ts` deployed to several environments has exactly one
+  per-environment lever, and it did nothing: production kept sending mail branded
+  with the repo-pinned name, and because the fallback sender is slugged from the
+  same value, the envelope said `no-reply@acme-dev.local` too.
+
+  `appName` is now resolved after the spread, in the order
+  `OS_APP_NAME` > `config.email.appName` >
+  `config.email.defaultTemplateContext.appName` > top-level `config.appName` >
+  `'ObjectStack'`. Every other key of `defaultTemplateContext` is unchanged — it
+  has no env or dedicated-config carrier, so the author's context is still spread
+  through wholesale.
+
+  **Behaviour change, accepted deliberately.** A deployment that relied on
+  `defaultTemplateContext.appName` beating `OS_APP_NAME` will now see the env
+  value in mail subjects, bodies and the derived fallback sender. Unset
+  `OS_APP_NAME` in that environment, or move the intended name into
+  `config.email.appName`, to keep the old result. Note that
+  `defaultTemplateContext.appName` stays in the chain rather than losing to the
+  two dedicated sources outright: a config that spells only the context form is
+  still honoured and is not demoted to `'ObjectStack'`.
+
+- 55dbbba: feat(spec,runtime,hono): `server.security.rateLimit` — an authored budget that actually returns 429 (#4910, #4937)
+
+  Rate limiting in ObjectStack was three shapes with nothing between them. `packages/spec`
+  declared `RateLimitConfig` in three places and the whole repo had **zero readers** for any
+  of them, so an author wrote a budget, it parsed, and nothing happened (#4686).
+  `@objectstack/runtime` shipped a token bucket whose comments claimed, in the present tense,
+  that the dispatcher called it and short-circuited with 429 — it had **zero call sites**
+  outside its own unit test, and the `DispatcherPluginConfig.rateLimit` field it told you to
+  tune did not exist (#4937). Neither half was broken; they were simply never connected, and
+  both were documented as if they were.
+
+  They are connected now, along one narrow path.
+
+  ## What you write
+
+  ```ts
+  export default defineStack({
+    manifest: {
+      /* … */
+    },
+    server: {
+      security: {
+        rateLimit: { enabled: true, windowMs: 60_000, maxRequests: 600 },
+      },
+      trustProxy: false,
+    },
+  });
+  ```
+
+  `server:` is a **new** top-level stack key. Nothing declared it before, so no existing
+  stack changes behaviour on upgrade — there is no configuration that was inert yesterday
+  and starts throttling today.
+
+  It is deliberately **narrow**: it carries `security.rateLimit` and `trustProxy` and
+  nothing else, because those are the two keys with a consumer. It is NOT the nine-key
+  `HttpServerConfigSchema` — the other seven have no reader and no authoring surface, and
+  mounting them here would have made seven dead keys writable in one move (their
+  enforce-or-remove fate stays with #4938). It is strict from birth (#4001), so a misspelled
+  budget is rejected with the correction rather than silently defaulted, and `maxRequests: 0`
+  is refused at `defineStack` rather than at 3am.
+
+  **No `server.port`.** The listening socket belongs to the deployment, not the artifact, and
+  `objectstack serve -p` already owns it. The precedence rule is recorded in the schema and
+  the docs in advance, so it cannot be re-litigated per caller: **CLI flag > `server:` >
+  built-in default.**
+
+  ## What happens
+
+  Every inbound request the server routes — REST, dispatcher, service routes, anything
+  mounted on that transport — consumes from a token bucket sized `capacity = maxRequests`,
+  refilling at `maxRequests / (windowMs / 1000)` per second. An empty bucket answers **429**
+  with a `Retry-After` computed from the bucket itself and the standard error envelope
+  (`code: "RATE_LIMIT_EXCEEDED"`). `OPTIONS` preflights are never metered.
+
+  The bucket is keyed by **resolved principal**, falling back to the caller's **IP** for
+  anonymous traffic — so one abusive session cannot spend another user's budget, and
+  credential-stuffing traffic (which has no principal yet) is still metered per source. That
+  IP comes from `X-Forwarded-For` / `X-Real-IP` **only when `trustProxy: true` is declared**;
+  otherwise it is the transport's own peer address. Undeclared, those headers are attacker
+  input: honouring them by default would hand anyone an unlimited supply of fresh buckets and
+  let them drain a chosen victim's.
+
+  Counters live in the kernel `cache` service when one is registered, so a multi-node
+  deployment enforces one budget instead of one per node (ADR-0069 D2), resolved lazily at
+  consume time so a cache plugin that registers later is still picked up (#4772). With no
+  cache service at all it falls back to a per-process store and says so once, naming the
+  consequence: the effective limit becomes the declared budget multiplied by the number of
+  nodes, and nothing about the deployment looks wrong.
+
+  ## Also in this change
+
+  - **`IHttpServer.use()` is a real middleware seam.** The Hono adapter's implementation
+    passed `{}` for both `req` and `res` and called `next()` unconditionally, so a registered
+    middleware could not read the request, write a response, or decline to continue — a
+    declared seam with no execution behind it, unnoticed because nothing called it. It now
+    delivers method/path/query/headers plus the transport peer address
+    (`IHttpRequest.remoteAddress`, new), and honours a short-circuit. Middleware must be
+    registered before the routes it guards; the kernel's two-phase boot makes that automatic
+    (`init()` before every `start()`).
+  - **`packages/runtime/src/security/rate-limit.ts` no longer describes an execution chain it
+    does not have** (#4937). The token-bucket arithmetic is extracted so the synchronous
+    in-process limiter and the new shared-store one cannot drift, and `DEFAULT_RATE_LIMITS` is
+    now labelled as the reference material it always was rather than as live defaults.
+
+  ## Explicitly NOT wired
+
+  `ApiEndpointSchema.rateLimit` and `ApiEndpointRegistrationSchema.rateLimit` remain
+  **known-unwired**. Declaring them still changes nothing. They are not retired here either:
+  the fate of the whole declarative `apis:` surface is undecided (#4936), and retiring one
+  key of a surface that may yet be implemented would only have to be undone. Tracked, not
+  silent.
+
+- dd98cba: `os doctor` reports an unreadable installed-package ledger under EVERY tenancy posture
+
+  The three rows that say doctor could not read `.objectstack/installed-packages/`
+  — the directory could not be enumerated, a file inside it would not parse, or
+  the package that reads ledgers would not load — were all produced inside the
+  ADR-0120 D5e unique-scope advisory, whose entry condition is
+  `postureGatesGlobalUniques(posture)`. That is true only for `isolated` (and its
+  legacy alias `multi`), so under `single` and `group` the ledger was never read
+  at all and `os doctor` said nothing about it. `OS_TENANCY_POSTURE` unset
+  resolves to `single`, so the silent posture was the default one.
+
+  Whether an environment's `unique: 'global'` is dangerous IS a posture question,
+  and that gate is unchanged. Whether a file in the ledger can be read is not: it
+  is equally true under every posture and means the same thing under every one —
+  that installed app is dropped at boot, absent from the kernel and from the
+  console's installed-apps list.
+
+  Ledger readability is now its own check, run unconditionally, independent of
+  both the posture and of whether an `objectstack.config.ts` loaded. The D5e block
+  keeps the unique-scope judgment alone, consuming the same reading rather than
+  taking a second one, so one bad ledger produces one row under `isolated` too. An
+  incomplete reading still withholds `✓ Unique scope` there — that line is a claim
+  about both halves of the advisory and only one of them ran.
+
+  **Report face:** the three readability rows now take the `Installed packages`
+  name column instead of `Unique scope`, and drop `for installation-wide uniques`
+  from the message's parenthetical — under `single` and `group` there is no
+  unique-scope check to name. This supersedes the sentence in the pending
+  `quiet-ledgers-speak-up` changeset that called it a `Unique scope` warning row.
+  The `Unique scope` name still exists, under the D5e block, for the unique-scope
+  verdict alone. A readable ledger prints nothing new under any posture.
+
+  This is the diagnostic-command half only. The runtime's own signal — the
+  `rehydrate()` warning per dropped entry at boot — is unchanged and stays
+  posture-independent; the two are separate channels for separate moments and
+  neither substitutes for the other.
+
+- 8c5a87c: `os lint`: dedup actions on their real engine key, not the bare name
+
+  `naming/namespace-prefix` deduplicated every bare-named type on `name` alone.
+  For actions that is not the key they occupy: the engine registers an action
+  under `objectName:name` (`ObjectQLPlugin.actionObjectKey`, with the canonical
+  object-less key `global` since #3913), so a package that declares one
+  `log_call` per object occupies one distinct key per object and nothing shadows
+  anything.
+
+  The bare-name dedup therefore flagged that shape as an intra-package duplicate
+  and the noise grew linearly with the object count — 12 fixed warnings per run
+  on HotCRM (5 objects x 3 activity actions), where following the "rename one"
+  prescription would have broken the shared i18n keys the shape depends on.
+  Actions now dedup on `objectName:name`; the other six types keep bare-name
+  dedup and their message text verbatim.
+
+  Genuine shadowing is still reported: two actions sharing one `objectName`, two
+  object-less actions sharing a name, and an action on an object literally named
+  `global` meeting an object-less one all still warn — with a remedy calibrated
+  for actions, which offers separating them by `objectName` before renaming.
+
+- 2ddba89: fix(tenancy): eight sites answered "is this deployment multi-org?" with the demoted `OS_MULTI_ORG_ENABLED` (#5262)
+
+  ADR-0105 D1 made `OS_TENANCY_POSTURE` the authoritative knob and demoted
+  `OS_MULTI_ORG_ENABLED` to a back-compat _input_ of `resolveTenancyPosture()`.
+  A deployment configured the documented way — `OS_TENANCY_POSTURE=isolated` (or
+  `group`), legacy boolean unset — therefore reads `false` from
+  `resolveMultiOrgEnabled()` while running a fully mounted organization wall.
+  #5233 corrected two sites in `plugin-auth`; a census found eight more, all
+  written before that function's doc comment was corrected. Third recurrence of
+  the shape (cloud#1020, #5233).
+
+  Each site was judged separately for **which** posture answers its question —
+  what the operator REQUESTED, or what the `tenancy` service reports is actually
+  IN FORCE — rather than converted mechanically:
+
+  - `objectql` `SchemaRegistry` — the env-derived multi-tenant default. Reads the
+    REQUESTED posture (it is constructed below the kernel, with no service
+    registry to ask). The `organization_id` column was always provisioned; what
+    diverged is its INDEX, so a posture-only deployment ran the Layer 0 wall's
+    hottest predicate unindexed while SecurityPlugin compiled that same wall.
+  - `plugin-dev` — whether to load the enterprise `@objectstack/organizations`.
+    REQUESTED posture, mirroring `serve.ts`: this branch is what mounts the wall,
+    so asking whether the wall is up would be circular. A posture-only dev stack
+    previously never loaded the package at all and served traffic unwalled. Its
+    diagnostic now names the posture that was requested instead of asserting
+    `OS_MULTI_ORG_ENABLED=true` at an operator who never set it.
+  - `runtime` `AppPlugin` (inline seed + hot-reload seeder) — EFFECTIVE posture,
+    via the `tenancy` service. These ask "will the per-org replay run instead of
+    me?", and on an ADR-0093 D5 degraded boot that replay does not exist, so
+    keying on the request would defer to a replay that can never happen. Walled
+    deployments previously inline-seeded exactly the NULL-organization rows the
+    code's own comment exists to avoid.
+  - `cloud-connection` marketplace local install (install-time seed + rehydrate
+    heal) — EFFECTIVE posture, same reasoning. The install path is a write path:
+    a walled deployment wrote every sample row with no `organization_id`, landing
+    the app's data outside the wall its own reads apply.
+  - `driver-sql` `isMultiTenantMode()` — REQUESTED posture (a driver has no
+    kernel to ask, and a suppressed warning is the costlier error for a
+    diagnostic). It also no longer memoises into `_multiTenantMode`: that froze a
+    process-level fact into a per-instance verdict on whichever write landed
+    first. The gate now resolves live, which is affordable because
+    `auditMissingTenant` consults it only after the `tenantId` early-out.
+  - `cli` `os verify` — REQUESTED posture. This one produced a green verification
+    run over an unverified property: a posture-only deployment silently skipped
+    every multi-tenant proof and exited 0.
+
+  **No configuration change is needed anywhere.** Deployments setting only
+  `OS_MULTI_ORG_ENABLED=true` keep working unchanged — `resolveTenancyPosture()`
+  falls back to it — and the `OS_TENANCY_POSTURE=isolated` + `OS_MULTI_ORG_ENABLED=true`
+  belt-and-braces configuration stays valid. Deployments that set only
+  `OS_TENANCY_POSTURE` can now drop the redundant boolean. Single-org behaviour is
+  unchanged at every site; only the knob each one reads is corrected.
+
+- 7127b48: `LocalManifestSource.list()` now reports the ledger entries it could NOT read
+
+  A truncated, unreadable or unparseable file under
+  `.objectstack/installed-packages/` was skipped in an un-bound per-file `catch`
+  and `list()` returned a bare array, so a short list was indistinguishable from a
+  complete one — no difference in the return value, no log, no count. Three
+  consumers gave a confidently wrong answer: the installed app was never
+  registered at boot (gone from the app switcher, its objects nonexistent) with
+  nothing in the log, the console's installed-apps list came back short with
+  `success: true`, and `os doctor` printed `✓ Unique scope` over manifests it had
+  never parsed.
+
+  Skipping a corrupt file stays correct — one bad manifest must not stop a runtime
+  booting the packages that are fine. Skipping it _silently_ was the defect.
+
+  **Breaking (`@objectstack/cloud-connection`):** `LocalManifestSource.list()`
+  returns `{ entries, skipped }` instead of `InstalledManifestEntry[]`.
+
+  - FROM: `const entries = source.list();`
+  - TO: `const { entries, skipped } = source.list();`
+
+  `skipped` is `Array< { file: string; cause: unknown } >` — the file's basename
+  and the object reading or parsing it threw, unwrapped. Callers that only want
+  the old behaviour read `.entries`; the point of the shape is that dropping
+  `skipped` is now something a caller has to do on purpose. Two new exported
+  types, `InstalledManifestListing` and `SkippedManifestEntry`.
+
+  Enumerating the ledger DIRECTORY still throws out of `list()` — unchanged, and a
+  different fact from "some files in it would not parse".
+
+  `os doctor` reports unparseable entries as a `Unique scope` warning row naming
+  each file with its cause, and withholds the `✓` success line, alongside the
+  directory-level row it already had.
+
+- df54254: fix(cli): 非法 `OS_TENANCY_POSTURE` 在 `serve` 最开头被显式拒绝,不再先伪装成「AuthPlugin 加载失败」(#5359)
+
+  `resolveTenancyPosture()`(`@objectstack/types`)对无法识别的值抛错,文案自称
+  「Refusing to boot rather than silently falling back to a posture with no
+  organization wall」。**拒绝本身一直是对的,错的是这个拒绝怎么传出去。**
+
+  `serve` 过去没有单独解析 posture,而是让抛错从「第一处读到它的地方」自然逃逸,而那个
+  位置恰好在 AuthPlugin 那个很宽的 `try` 里 —— 它的 catch 只打印一句黄字就继续。于是一个
+  env 拼写错误的第一现场是:
+
+  ```
+    ⚠ AuthPlugin failed to load: Invalid OS_TENANCY_POSTURE="bogus". Expected one of: …
+  ```
+
+  把环境变量拼错报成了插件加载问题。启动随后**带伤继续**:整个 capability slate 照常装载,
+  本地 crypto 密钥被生成并**持久化到磁盘**,直到下一处没有被 `try` 包住的读取
+  (ObjectQL `SchemaRegistry` 构造,内核 bootstrap 阶段一)才让 `runtime.start()` 中止,
+  最终由通用 `printError` 把解析器那句话裸着打出来 —— 退出码对,别的都不对。
+
+  **现在的行为。** `serve.run()` 在 `dotenv-flow` 载入之后、读取配置文件之前、任何 `try`
+  之外解析一次 posture。非法值走 ADR-0093 D5 同款形状的显式拒绝 —— FATAL + 完整修法清单 +
+  `process.exit(1)`(不是 throw,throw 正是会被下游 catch 降级成 warning 的那种东西):
+
+  ```
+    ✖ FATAL: OS_TENANCY_POSTURE="bogus" is not a recognized tenancy posture.
+      Refusing to boot. …
+
+      No config has been loaded, no plugin has been mounted, and the HTTP server was
+      never started — this deployment has not served a single request.
+
+      Fix one of:
+        • set OS_TENANCY_POSTURE=single — …
+        • set OS_TENANCY_POSTURE=group — …
+        • set OS_TENANCY_POSTURE=isolated — …
+        • unset OS_TENANCY_POSTURE entirely — …
+
+      cause: Invalid OS_TENANCY_POSTURE="bogus". …
+  ```
+
+  修法清单由 `@objectstack/spec/security` 的 `TENANCY_POSTURES` 生成,不是第二份字面量,
+  所以新增一个 posture 不会让这段建议悄悄过期。文案里点名 `.env` —— 该变量常常来自提交进
+  仓库的 `.env*` 而不是 shell,这也是把闸门放在 dotenv 载入**之后**的原因。
+
+  `serve` 内后续所有 posture 读取(组织插件装载判断、启动横幅的 `Tenancy:` 行)改为复用
+  闸门解析出的那一个值,不再各自重新解析。横幅那处尤其值得说:它此前是非法 posture 的
+  **最后一道防线**,等于让一个诊断输出承担安全属性 —— 现在闸门拥有这个拒绝,横幅只负责
+  汇报闸门的结论。
+
+  **一处订正。** #5359 的静态追踪认为进程「在报错前已经 listen 过」。实测并非如此:逃逸的
+  抛错发生在内核 bootstrap **阶段一**(插件 init),而监听套接字在**阶段四**的
+  `kernel:listening` 钩子才打开,所以端口从未被绑定过 —— 修复前后都是如此。本次真正改变的
+  是:拒绝成为第一条也是唯一一条输出、归因正确、带处方,且启动不再留下任何副作用
+  (修复前那次「被拒绝」的启动会在磁盘上留下持久化的 dev crypto key)。
+
+- 41c3b48: feat(plugin-email): real SMTP delivery — `SmtpTransport`, settings hot-swap, and a `mail/test` that actually sends (#5087)
+
+  The **Mail Delivery** settings page has always defaulted to SMTP and offered a
+  full host / port / TLS / username / password form. Nothing behind it delivered:
+  `applyMailSettings` treated `provider: 'smtp'` as a no-op ("transport
+  unchanged"), `mail/test` answered `ok: true, "Configuration looks valid … Wire
+@objectstack/plugin-mail for actual delivery"` — a success toast for a message
+  nobody sent, naming a package that has never existed — and the code pointed
+  operators at `@objectstack/plugin-mail-smtp`, which is not in this repo or on
+  npm. A workspace that selected SMTP got a green form, a green test button, and
+  mail that only ever reached the log and the `sys_email` table. For deployments
+  in China this left **no** working channel at all: Resend and Postmark are
+  overseas HTTPS SaaS with unreliable reach and deliverability to QQ / 163 /
+  enterprise mailboxes, where SMTP is the normal path (Aliyun DirectMail, Tencent
+  SES, corporate mail servers).
+
+  **`SmtpTransport` now ships in `@objectstack/plugin-email`** (ADR-0012: SMTP in
+  core, implemented with `nodemailer`). `nodemailer` is a real dependency but is
+  imported **lazily on the first send**, so deployments that never select SMTP —
+  and non-Node runtimes — never load `node:net` / `node:tls`.
+
+  Three doors reach it, all sharing one options reader so they cannot drift:
+
+  - **Settings → Mail** (`smtp_host` / `smtp_port` / `smtp_secure` / `smtp_user` /
+    `smtp_password`) hot-swaps the live transport on save, no restart.
+  - **`os serve`** via `OS_EMAIL_PROVIDER=smtp` plus the new `OS_EMAIL_SMTP_HOST` /
+    `_PORT` / `_SECURE` / `_USER` / `_PASSWORD` (or `config.email.options`).
+  - **Constructor**: `new EmailServicePlugin({ provider: 'smtp', providerOptions:
+{ host, port, secure, user, password } })`.
+
+  TLS is one toggle with the wire behaviour derived from the port, as providers
+  document it: on `465` implicit TLS (SMTPS); on any other port a **required**
+  STARTTLS upgrade, so a server that refuses to upgrade fails the send instead of
+  leaking credentials over a cleartext socket; `secure: false` connects in the
+  clear and upgrades only when STARTTLS is offered.
+
+  **Failure is loud everywhere, because a silent fallback is the bug this fixes.**
+  On the construction path (CLI / plugin options) a `smtp` provider with no host
+  **throws** and the boot fails — it no longer degrades into a LogTransport that
+  reports every send as successful. On the settings hot-swap path a save can never
+  kill a running server, so the previous transport is kept — but the failure is
+  logged at `error` naming the consequence and the fix, and **`mail/test` now
+  performs a real delivery** through the settings on screen and reports the SMTP
+  server's own words (`535 … authentication failed`) instead of a green toast. The
+  built-in fallback `mail/test` handler (used only when no email plugin is
+  mounted) answers `ok: false` and says plainly that nothing was sent.
+
+  Nothing to migrate: `log`, `resend` and `postmark` behave exactly as before, and
+  a deployment that never selects `smtp` is unaffected.
+
+- a287d1c: fix(cli): `OS_STORAGE_ROOT` now actually takes effect — renamed to `OS_STORAGE_LOCAL_ROOT`, the name the settings service reads (#4968)
+
+  The CLI and the settings service spelled the local storage root differently.
+  The CLI wrote its own invented name, `OS_STORAGE_ROOT`; the settings service
+  derives the env name for the same value from the namespace it owns —
+  `envKeyOf('storage', 'local_root')` = `OS_STORAGE_LOCAL_ROOT` — and nothing in
+  the repo ever set that. So the two channels never met: `os serve` constructed a
+  local adapter at the root the operator named, `StorageServicePlugin` re-resolved
+  from settings at `kernel:ready`, found only the manifest's **schema default**,
+  and swapped the adapter to `./.objectstack/data/uploads`.
+
+  `OS_STORAGE_ROOT` therefore took effect for exactly one value — the one that
+  happens to equal that default — which is why plain `pnpm dev` never showed it.
+  Every other value was constructed and then discarded:
+
+  - **Production**: `OS_STORAGE_ROOT=/srv/uploads` was ignored and uploads landed
+    under the process cwd. An operator following `backup-restore.mdx` backed up an
+    empty directory.
+  - **`dev --fresh`**: the tempdir was documented to own all state for the run;
+    uploads actually went to the project cwd and survived process exit.
+  - Every clean boot logged a data-loss-grade "adapter swapped … existing files
+    were NOT migrated" warning. That warning was **accurate** — the swap really
+    happened — and is untouched here. It stops firing because the swap stops.
+
+  The fix is at the producer, not as a tolerant read in the consumer: `dev.ts`
+  publishes `OS_STORAGE_LOCAL_ROOT`, and `serve.ts` resolves the root through one
+  channel (`resolveStorageLocalRootEnv`), shared with `os migrate`'s storage
+  bootstrap so the CLI materialises bytes exactly where the server would.
+
+  `OS_STORAGE_ROOT` keeps working for **one release** via
+  `readEnvWithDeprecation('OS_STORAGE_LOCAL_ROOT', 'OS_STORAGE_ROOT')`, warning
+  once per process, and is then removed. When the legacy name supplies the value
+  it is also stamped onto the canonical name, because the settings service only
+  ever looks up `OS_STORAGE_LOCAL_ROOT` — without the stamp a deployment on the
+  old spelling would keep the original defect in full.
+
+  Storage settings now resolve `source: 'env'` at the value the adapter was built
+  with, so Setup → Settings → File Storage shows the directory actually in use.
+  No change to `packages/services/service-storage` — the swap predicate is correct
+  and stays as is.
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [da5d1b4]
+- Updated dependencies [d4e0809]
+- Updated dependencies [739f496]
+- Updated dependencies [c1e67e0]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [c637387]
+- Updated dependencies [c113690]
+- Updated dependencies [f7df82c]
+- Updated dependencies [705efeb]
+- Updated dependencies [978fed2]
+- Updated dependencies [c36abfe]
+- Updated dependencies [9ecdca9]
+- Updated dependencies [cfc293f]
+- Updated dependencies [d085670]
+- Updated dependencies [de70b42]
+- Updated dependencies [1792384]
+- Updated dependencies [2f6516e]
+- Updated dependencies [e6b1bb0]
+- Updated dependencies [a7b854f]
+- Updated dependencies [01c0bae]
+- Updated dependencies [f56ebea]
+- Updated dependencies [64cd010]
+- Updated dependencies [f522e95]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [628b028]
+- Updated dependencies [b857356]
+- Updated dependencies [fce4c73]
+- Updated dependencies [f6385c7]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [7e5ac28]
+- Updated dependencies [19e1a8f]
+- Updated dependencies [553a47f]
+- Updated dependencies [c5e7bd9]
+- Updated dependencies [0162c81]
+- Updated dependencies [055f0c9]
+- Updated dependencies [7a40b7a]
+- Updated dependencies [7cf1531]
+- Updated dependencies [586d6f7]
+- Updated dependencies [9f747ee]
+- Updated dependencies [2d14b35]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [c497d26]
+- Updated dependencies [e96ad55]
+- Updated dependencies [bbdbf28]
+- Updated dependencies [93929c2]
+- Updated dependencies [2e284b2]
+- Updated dependencies [3905c00]
+- Updated dependencies [4335497]
+- Updated dependencies [75bb3af]
+- Updated dependencies [43ca399]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [bcfebb0]
+- Updated dependencies [de770bf]
+- Updated dependencies [aa25a81]
+- Updated dependencies [3a18e24]
+- Updated dependencies [533a0a4]
+- Updated dependencies [1f82d1e]
+- Updated dependencies [a019e52]
+- Updated dependencies [02a8256]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [b746aa0]
+- Updated dependencies [ce1155c]
+- Updated dependencies [846ed1f]
+- Updated dependencies [947d4f9]
+- Updated dependencies [d8f65fe]
+- Updated dependencies [58ffcab]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [3133cda]
+- Updated dependencies [1f0e7cb]
+- Updated dependencies [8dbd2a8]
+- Updated dependencies [99d7a93]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c794f78]
+- Updated dependencies [f205c32]
+- Updated dependencies [7bf3d1c]
+- Updated dependencies [9ce0ca9]
+- Updated dependencies [db9c331]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [217b791]
+- Updated dependencies [fd8521f]
+- Updated dependencies [641363a]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [2b63a00]
+- Updated dependencies [06ba036]
+- Updated dependencies [18b8eaa]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [9c4f174]
+- Updated dependencies [d25f20b]
+- Updated dependencies [205e81b]
+- Updated dependencies [37e38d1]
+- Updated dependencies [cc5b048]
+- Updated dependencies [78adc2e]
+- Updated dependencies [0f17114]
+- Updated dependencies [81e2744]
+- Updated dependencies [277eb36]
+- Updated dependencies [41e605e]
+- Updated dependencies [ecc61ab]
+- Updated dependencies [2649ccb]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [a70cd0a]
+- Updated dependencies [c52e608]
+- Updated dependencies [96d3d4d]
+- Updated dependencies [afa6aa5]
+- Updated dependencies [afb83d3]
+- Updated dependencies [4022b78]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [06ffad3]
+- Updated dependencies [811c30c]
+- Updated dependencies [2b2175b]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [c7406b0]
+- Updated dependencies [85d95e7]
+- Updated dependencies [8108787]
+- Updated dependencies [168f60f]
+- Updated dependencies [d4edb5d]
+- Updated dependencies [eb26126]
+- Updated dependencies [be59695]
+- Updated dependencies [b2e1057]
+- Updated dependencies [ec6fad8]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [58f3220]
+- Updated dependencies [07f1822]
+- Updated dependencies [729a43a]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [08f93bc]
+- Updated dependencies [d9971d3]
+- Updated dependencies [d97f2a2]
+- Updated dependencies [d9cac60]
+- Updated dependencies [eb3e650]
+- Updated dependencies [abeb375]
+- Updated dependencies [dfa8bad]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [290d944]
+- Updated dependencies [02dc076]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [123067c]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [88a6bed]
+- Updated dependencies [a6b3ee7]
+- Updated dependencies [7f1a635]
+- Updated dependencies [e98fb14]
+- Updated dependencies [5d3ced9]
+- Updated dependencies [4b50be4]
+- Updated dependencies [9fa6bab]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [1b9a53b]
+- Updated dependencies [61dc08e]
+- Updated dependencies [8dcf607]
+- Updated dependencies [b691ba9]
+- Updated dependencies [65159ae]
+- Updated dependencies [1eadac0]
+- Updated dependencies [7c2f7dd]
+- Updated dependencies [9b26699]
+- Updated dependencies [461ccda]
+- Updated dependencies [5582e18]
+- Updated dependencies [58f3220]
+- Updated dependencies [f238970]
+- Updated dependencies [06fc07a]
+- Updated dependencies [61fde5e]
+- Updated dependencies [95b4f0d]
+- Updated dependencies [877545c]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [444a07c]
+- Updated dependencies [288e5a4]
+- Updated dependencies [46365ab]
+- Updated dependencies [e18e3da]
+- Updated dependencies [b508244]
+- Updated dependencies [8597a7d]
+- Updated dependencies [5a45b9b]
+- Updated dependencies [594508e]
+- Updated dependencies [60a7a2d]
+- Updated dependencies [ff39e63]
+- Updated dependencies [1c625ca]
+- Updated dependencies [b5459bc]
+- Updated dependencies [1624f4a]
+- Updated dependencies [e6db317]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [c5adfe1]
+- Updated dependencies [26e1029]
+- Updated dependencies [1cae606]
+- Updated dependencies [2f1e2a5]
+- Updated dependencies [4addd9d]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b9cc17d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [340a34f]
+- Updated dependencies [a9f32df]
+- Updated dependencies [75f82f3]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [1203bb2]
+- Updated dependencies [7d27da0]
+- Updated dependencies [b821b29]
+- Updated dependencies [af96af6]
+- Updated dependencies [de113a4]
+- Updated dependencies [caf144a]
+- Updated dependencies [db8c285]
+- Updated dependencies [0d24078]
+- Updated dependencies [089767f]
+- Updated dependencies [5b8f95b]
+- Updated dependencies [da538b1]
+- Updated dependencies [dadf542]
+- Updated dependencies [2ddba89]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [79822b5]
+- Updated dependencies [15e61fb]
+- Updated dependencies [ef7845a]
+- Updated dependencies [72bd873]
+- Updated dependencies [7127b48]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [73580e7]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [dde9202]
+- Updated dependencies [2cca98b]
+- Updated dependencies [07f1822]
+- Updated dependencies [37a8f2b]
+- Updated dependencies [441d79f]
+- Updated dependencies [7f955e5]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [9c5abf4]
+- Updated dependencies [dc6abfd]
+- Updated dependencies [39396bd]
+- Updated dependencies [577cd27]
+- Updated dependencies [5897552]
+- Updated dependencies [91ec1ea]
+- Updated dependencies [2d25303]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [bf1edef]
+- Updated dependencies [7b005b4]
+- Updated dependencies [da1a64c]
+- Updated dependencies [5e3c83b]
+- Updated dependencies [0cd08d5]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5ab0842]
+- Updated dependencies [5c94f83]
+- Updated dependencies [d275c10]
+- Updated dependencies [f98fa65]
+- Updated dependencies [73e576f]
+- Updated dependencies [2680cd3]
+- Updated dependencies [1d29e6d]
+- Updated dependencies [c5a5996]
+- Updated dependencies [5ea8e1e]
+- Updated dependencies [cba7454]
+- Updated dependencies [b40f81c]
+- Updated dependencies [82a06af]
+- Updated dependencies [6e66cbe]
+- Updated dependencies [f226605]
+- Updated dependencies [c272e48]
+- Updated dependencies [ddd6650]
+- Updated dependencies [db2ea82]
+- Updated dependencies [51a587d]
+- Updated dependencies [ae490ef]
+- Updated dependencies [1216dcc]
+- Updated dependencies [9c90ea0]
+- Updated dependencies [41c3b48]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [193cd5c]
+- Updated dependencies [5aae790]
+- Updated dependencies [07f1822]
+- Updated dependencies [ef8b1ff]
+- Updated dependencies [1f1edc0]
+- Updated dependencies [718b229]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [d56bcdb]
+- Updated dependencies [f104bab]
+- Updated dependencies [dca25e1]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [5aaa6fc]
+- Updated dependencies [dca5bd3]
+- Updated dependencies [488b66c]
+- Updated dependencies [20963e7]
+- Updated dependencies [c89d18c]
+- Updated dependencies [acf34e3]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [90fa077]
+- Updated dependencies [e92e2c3]
+- Updated dependencies [946a131]
+- Updated dependencies [909895d]
+- Updated dependencies [38f53a0]
+- Updated dependencies [c183a12]
+- Updated dependencies [69a89ce]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+- Updated dependencies [c42a19a]
+- Updated dependencies [f0d98e1]
+- Updated dependencies [229d29e]
+- Updated dependencies [b508244]
+- Updated dependencies [2b52bc8]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/runtime@17.0.0-rc.4
+  - @objectstack/lint@17.0.0-rc.4
+  - @objectstack/types@17.0.0-rc.4
+  - @objectstack/cloud-connection@17.0.0-rc.4
+  - @objectstack/driver-sql@17.0.0-rc.4
+  - @objectstack/service-analytics@17.0.0-rc.4
+  - @objectstack/driver-memory@17.0.0-rc.4
+  - @objectstack/rest@17.0.0-rc.4
+  - @objectstack/core@17.0.0-rc.4
+  - @objectstack/plugin-hono-server@17.0.0-rc.4
+  - @objectstack/metadata-protocol@17.0.0-rc.4
+  - @objectstack/metadata@17.0.0-rc.4
+  - @objectstack/platform-objects@17.0.0-rc.4
+  - @objectstack/plugin-approvals@17.0.0-rc.4
+  - @objectstack/plugin-audit@17.0.0-rc.4
+  - @objectstack/plugin-auth@17.0.0-rc.4
+  - @objectstack/service-settings@17.0.0-rc.4
+  - @objectstack/objectql@17.0.0-rc.4
+  - @objectstack/plugin-email@17.0.0-rc.4
+  - @objectstack/service-sms@17.0.0-rc.4
+  - @objectstack/client@17.0.0-rc.4
+  - @objectstack/service-automation@17.0.0-rc.4
+  - @objectstack/console@17.0.0-rc.4
+  - @objectstack/plugin-security@17.0.0-rc.4
+  - @objectstack/service-datasource@17.0.0-rc.4
+  - @objectstack/driver-mongodb@17.0.0-rc.4
+  - @objectstack/driver-sqlite-wasm@17.0.0-rc.4
+  - @objectstack/formula@17.0.0-rc.4
+  - @objectstack/verify@17.0.0-rc.4
+  - @objectstack/service-queue@17.0.0-rc.4
+  - @objectstack/trigger-record-change@17.0.0-rc.4
+  - @objectstack/plugin-sharing@17.0.0-rc.4
+  - @objectstack/mcp@17.0.0-rc.4
+  - @objectstack/service-messaging@17.0.0-rc.4
+  - @objectstack/service-storage@17.0.0-rc.4
+  - @objectstack/account@17.0.0-rc.4
+  - @objectstack/setup@17.0.0-rc.4
+  - @objectstack/observability@17.0.0-rc.4
+  - @objectstack/plugin-reports@17.0.0-rc.4
+  - @objectstack/plugin-webhooks@17.0.0-rc.4
+  - @objectstack/service-cache@17.0.0-rc.4
+  - @objectstack/service-job@17.0.0-rc.4
+  - @objectstack/service-package@17.0.0-rc.4
+  - @objectstack/service-realtime@17.0.0-rc.4
+  - @objectstack/trigger-api@17.0.0-rc.4
+  - @objectstack/trigger-schedule@17.0.0-rc.4
+  - @objectstack/plugin-pinyin-search@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Major Changes
diff --git a/packages/cli/package.json b/packages/cli/package.json
index d0433d0ac3..4a6de3a445 100644
--- a/packages/cli/package.json
+++ b/packages/cli/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/cli",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "description": "Command Line Interface for ObjectStack Protocol",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",
diff --git a/packages/client-react/CHANGELOG.md b/packages/client-react/CHANGELOG.md
index 69b4442af5..7a405e49ef 100644
--- a/packages/client-react/CHANGELOG.md
+++ b/packages/client-react/CHANGELOG.md
@@ -1,5 +1,195 @@
 # @objectstack/client-react
 
+## 17.0.0-rc.4
+
+### Major Changes
+
+- d9cac60: **BREAKING** — `GET /meta/:type/:name` now answers exactly one body shape: the
+  `GetMetaItemResponseSchema` envelope `{ type, name, item, … }` that
+  `packages/spec` has always declared for it. On the default configuration this
+  endpoint used to answer the **bare metadata document** instead (#5563).
+
+  ### What changed, and why it is breaking
+
+  The route had two mutually exclusive branches with different response
+  structures. The cached branch — reached whenever `metadata.enableCache` is on,
+  which is the **default** (`enableCache: z.boolean().default(true)`) — served
+  `getMetaItemCached`'s `result.data`, and that value has the envelope already
+  stripped. The uncached branch served `getMetaItem`'s envelope. So the one shape
+  the spec declared was the one a default deployment could not obtain, and the
+  envelope surfaced only when the cache was off or when the read structurally
+  bypassed it (`app`, `doc`, `book`, `?state=draft`, `?preview=draft`,
+  `?package=`). Consumers had no correct static type — they sniffed at runtime or
+  reached for `as any` (#5545 was blocked on exactly this).
+
+  The dispatcher's `/meta` domain had the same split one layer down: the protocol
+  resolver answered the envelope while the ObjectQL-registry and MetadataService
+  fallbacks answered bare documents. Both fallbacks now wrap what they found,
+  taking `type`/`name` from the request.
+
+  ### Migration
+
+  `GET /api/v1/meta/object/customer`, default configuration:
+
+  ```jsonc
+  // before — the bare document
+  { "name": "customer", "label": "Customer", "fields": { /* … */ } }
+
+  // after — the declared envelope; the document is verbatim under `item`
+  {
+    "type": "object",
+    "name": "customer",
+    "item": { "name": "customer", "label": "Customer", "fields": { /* … */ } }
+  }
+  ```
+
+  - **Reading the body directly** (`fetch`, `client.meta.getItem`,
+    `client.meta.getCached().data`): read the document at `.item`. Nothing inside
+    it changed. `type` is the canonical singular metadata type name, so
+    `/meta/objects/customer` and `/meta/object/customer` answer the same `type`.
+  - **`useObject` / `useFields` (`@objectstack/client-react`)**: `useObject().data`
+    is now the envelope — `data.item.label`, `data.item.fields`, where it used to
+    be `data.label` / `data.fields`. `useFields()` is unchanged (it already
+    returns the flattened field list) and is the shorter path when fields are all
+    you need.
+  - **`isMetaEnvelope`, exported from `@objectstack/rest`, is REMOVED.** It
+    existed only to tell the two shapes apart. There is one shape now, so the
+    replacement for `isMetaEnvelope(r) ? r.item : r` is `r.item`.
+  - **Not converged, deliberately**: `?layers=true` still answers the layered
+    diagnostic projection `{ type, name, code, overlay, overlayScope, effective,
+validation }`. Collapsing three layers into one `item` would delete the
+    diagnostic. Unaffected unless you pass that flag.
+
+### Patch Changes
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [aa25a81]
+- Updated dependencies [3a18e24]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [b746aa0]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [d9971d3]
+- Updated dependencies [eb3e650]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [46365ab]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [c5adfe1]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/core@17.0.0-rc.4
+  - @objectstack/client@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Minor Changes
diff --git a/packages/client-react/package.json b/packages/client-react/package.json
index 6378c42f0b..46bbbfbe6b 100644
--- a/packages/client-react/package.json
+++ b/packages/client-react/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/client-react",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "React hooks for ObjectStack Client SDK",
   "main": "dist/index.js",
diff --git a/packages/client/CHANGELOG.md b/packages/client/CHANGELOG.md
index c0c989a3df..f2ef41f7b6 100644
--- a/packages/client/CHANGELOG.md
+++ b/packages/client/CHANGELOG.md
@@ -1,5 +1,378 @@
 # @objectstack/client
 
+## 17.0.0-rc.4
+
+### Major Changes
+
+- aa25a81: fix(client)!: `DeleteDataResult` declares the schema it names — `success`, not `deleted` (#5638)
+
+  `DeleteDataResult` — the return type of `client.data.delete()` and of the
+  project-scoped `client.project(id).data.delete()` — carried the comment
+  `Spec: DeleteDataResponseSchema` above a declaration that contradicted it:
+
+  ```ts
+  /** Spec: DeleteDataResponseSchema */
+  export interface DeleteDataResult {
+    object: string;
+    id: string;
+    deleted: boolean; // ← the schema declares `success`
+  }
+  ```
+
+  `DeleteDataResponseSchema` (`packages/spec/src/api/protocol.zod.ts`) declares
+  `{ object, id, success }`. `deleted` has never been declared by any schema, and
+  no server path has ever returned it on `/data/:object/:id`.
+
+  **The old key was never readable at runtime — this rename reveals a defect, it
+  does not break working code.** Both `delete` surfaces are pure `unwrapResponse`
+  / `_unwrap` passthroughs: the SDK returns the server's body untouched, so this
+  interface is a _claim_ about the wire, never a rewrite of it. The claim was
+  false in the one direction that matters — the compiler endorsed the wrong
+  spelling:
+
+  ```ts
+  const r = await client.data.delete('task', id);
+  if (r.deleted) { … }   // compiled; `undefined` at runtime; branch never taken
+  if (r.success) { … }   // rejected by the compiler; correct on the wire
+  ```
+
+  ## What to change
+
+  `r.deleted` → `r.success`. That is the whole migration. Nothing about the
+  request, the route, the status codes or the error shapes changes, and no server
+  needs upgrading: the value you are now allowed to read is the one that was
+  already arriving.
+
+  ⛔ **Do not write `r.success ?? r.deleted`.** There is one producer shape, and a
+  consumer that accepts two spellings is the shape contract-first exists to
+  prevent — the same ruling #5581 applied on the producer side. No deprecated
+  `deleted?: boolean` transition key ships for the same reason; a transition
+  period is for keys that _worked_, and this one never did.
+
+  ## Why the type was wrong on every deployment, not just some
+
+  The protocol path (`deleteData`) has always answered `success`. #5581 / PR
+  #5641 brought the ObjectQL fallback — the path a slim assembly without
+  `MetadataPlugin` takes — to the same shape. So before that fix the declaration
+  was wrong on ordinary deployments and accidentally right on slim ones; after
+  it, both paths answer `{ object, id, success }` and the declaration was simply
+  wrong everywhere. The consumer-side correction had to follow the producer, not
+  lead it.
+
+  ## `os data delete` was reading the phantom key too
+
+  `packages/cli/src/commands/data/delete.ts` built its `--format json` / `--format
+yaml` payload with `deleted: result.deleted`. That evaluated to `undefined`, and
+  `JSON.stringify` drops undefined values — so the `deleted` key the command has
+  always declared **never appeared in a single run**. It now carries
+  `result.success`, the server's own verdict.
+
+  Observable change: `os data delete --format json` gains `deleted: true` (YAML
+  likewise) on a successful delete. The key name stays `deleted` deliberately —
+  it is the CLI's output key, not the protocol's, and the payload's top-level
+  `success` already means something different (the CLI envelope's "the command
+  completed"). Conflating the two is the hazard #5641 called out when it noted
+  that `body.success` and `body.data.success` are different facts. Scripts
+  reading `.deleted` from this command were reading `undefined` before and get a
+  boolean now; nothing that worked stops working.
+
+  ## Downstream
+
+  `objectui`'s `ObjectStackDataSource.delete()` is a live victim of the old
+  declaration — it guards `emitMutation` on `result.deleted`, so the delete
+  mutation event has never fired against a real server and the method returns
+  `undefined` where it declares `boolean`. Its own suite stayed green because the
+  fixture mocks `{ deleted: true }`, a body no server produces. Filed as
+  objectstack-ai/objectui#3412, which is blocked on this package publishing —
+  its fix is a type unblock, not a behaviour change, since `success` is already
+  what arrives.
+
+  ## Pins
+
+  `packages/client/src/data-delete-result-shape.test.ts` asserts mutual
+  assignability between `DeleteDataResult` and the spec's `DeleteDataResponse`,
+  so a rename on either side (or a re-added optional `deleted`) fails
+  `check:test-typecheck`. `client.hono.test.ts` gains the delete case this live
+  server suite never had: a real DELETE over HTTP whose body is read as
+  `deleted.success` and whose key set is asserted literally — `z.object` strips
+  unknown keys, so a passing parse alone cannot prove no stray `deleted` rode
+  along.
+
+### Patch Changes
+
+- 3a18e24: client SDK: `meta.getItem` / `meta.saveItem` declare their spec response types on both surfaces
+
+  `ObjectStackClient.meta` and `ScopedProjectClient.meta` each carried a `getItem`
+  and a `saveItem` with no return-type annotation, so `unwrapResponse` / `_unwrap`
+  resolved without a type argument and every caller received `unknown` — while the
+  `getItems` sitting one line above returned `GetMetaItemsResponse`. Two adjacent
+  methods on one surface, unequal typing (#5545).
+
+  Both now name the type `@objectstack/spec` already declares for their route, and
+  both types are re-exported from `@objectstack/client` so a caller can name what
+  it received:
+
+  - `getItem` → `Promise< GetMetaItemResponse >` — the `{ type, name, item }`
+    envelope. This became the only honest annotation with #5563: before it, the
+    route's default (cached) path answered the bare document and the non-cached
+    path the envelope, so no single type described both.
+  - `saveItem` → `Promise< SaveMetaItemResponse >` — including `version`, the
+    ADR-0008 optimistic-concurrency token a caller echoes back as `If-Match`.
+    Nameable only since #5745 completed that schema; against the older
+    `{ success, message }` declaration the annotation would have hidden the OCC
+    carrier.
+
+  `patch`, not `minor`: this only narrows `unknown` on existing public signatures.
+  `unknown` admits no property read and no assignment to a typed binding, so every
+  expression that compiled before still compiles — nothing is removed, and no new
+  method or option appears.
+
+- c001422: feat(spec): declare `routes.mcp` on `ApiRoutesSchema`, and extend the discovery conformance gate one level down (#5679)
+
+  `/discovery` advertises `routes.mcp`, `objectui` reads it, and
+  `ApiRoutesSchema` never declared it. This is #4828's defect one level down —
+  with the opposite disposition: `endpoints` was retired because a census found
+  no reader, while `mcp` has two real ones (`ConnectAgentWidget.tsx` and
+  `AgentConnectSection.tsx` both gate the Integrations connect card on it), and
+  it is in fact the only `routes.*` key anything in `objectui` reads. So it is
+  declared, not removed.
+
+  Why it was a defect and not tidiness: `ApiRoutesSchema` is a plain `z.object`,
+  which **strips** unknown keys. Any consumer parsing `/discovery` through the
+  spec dropped `routes.mcp` silently — the connect card would blank with no
+  error. Nothing broke yet only because those two readers happen to read raw
+  JSON.
+
+  - **`ApiRoutesSchema` declares `mcp: z.string().optional()`**, as measured off
+    both producers rather than guessed: a path string (`/api/v1/mcp`), always the
+    **unscoped** base — `/mcp` is mounted bare, so a scoped mount advertising
+    `/api/v1/environments/env_alpha/data` still advertises `/api/v1/mcp` — and
+    `optional`, not `nullable`: the key is absent (rest-server `delete`s it, the
+    dispatcher leaves it `undefined`) when MCP is disabled or unserveable.
+    Neither producer ever emits `null`.
+  - **`@objectstack/rest` drops the two `as any` casts** at the emit site. That is
+    type-only — the emitted body is byte-identical — but the cast's disappearance
+    is the structural proof: with the key undeclared, removing it produced two
+    `TS2339 Property 'mcp' does not exist`; with it declared, `tsc --noEmit`
+    returns to its ratcheted baseline.
+  - **The #4828 conformance gates now cover `routes` keys**, not just top-level
+    ones, in all three producer packages, deriving the allowance from
+    `ApiRoutesSchema` the same way the top-level check derives it from the
+    protocol schema. Extended one level, not recursed — full recursion stays out
+    of scope, and `capabilities` / `services` are `z.record`s whose keys are open
+    by design.
+
+  - **`@objectstack/client`'s conventional route table gains an `mcp` row.** That
+    table is `Record<keyof ApiRoutes, string>` — total by design — so a newly
+    declared route owes a convention, and the public `ApiRouteType` (`keyof
+ApiRoutes`) widens by one member. The path is `/api/v1/mcp`, which is what
+    both producers emit, so the fallback agrees with the discovered value instead
+    of competing with it. Resolution behaviour is unchanged: `getRoute()` still
+    prefers the discovered route, and the pre-existing catch-all already produced
+    the same string.
+
+  Corrects one detail of the issue's premise: the runtime dispatcher's
+  `getDiscoveryInfo()` **does** also emit `routes.mcp` (its routes literal always
+  carries the key, holding the path or `undefined`), so both producers were
+  affected, not just REST — and the new gate went red on both before the fix.
+
+- aac90a5: feat(spec,runtime,metadata-protocol,client)!: one closed capability vocabulary — every discovery producer emits every key (#5672)
+
+  `#4828` renamed the runtime dispatcher's top-level `features` map to the
+  canonical `capabilities`, which collapsed the _spelling_ split between the two
+  discovery producers. It did not touch the deeper one: the two went on filling
+  **disjoint key sets**.
+
+  | producer                                                                             | keys it filled                                                                        |
+  | :----------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------ |
+  | `getDiscovery()` — `@objectstack/metadata-protocol`, upstream of REST `/discovery`   | `comments` `automation` `cron` `search` `export` `chunkedUpload` `transactionalBatch` |
+  | `getDiscoveryInfo()` — `@objectstack/runtime` dispatcher, `/.well-known/objectstack` | `search` `websockets` `files` `analytics` `ai` `notifications` `i18n`                 |
+
+  Only `search` overlapped. `DiscoverySchema.capabilities` was an open
+  `z.record`, so both shapes parsed clean and no gate could see the split — while
+  `packages/client`'s `capabilities` getter **asserted** the result was a
+  `WellKnownCapabilities`. Against a dispatcher-served host
+  `client.capabilities.transactionalBatch` was therefore statically `boolean` and
+  actually `undefined`, as were `comments`, `cron`, `export` and `chunkedUpload`.
+
+  Per the maintainer's 2026-08-06 ruling, the vocabulary is now closed and
+  mandatory.
+
+  **What a consumer sees.** Before: which capability flags exist depended on
+  which kind of host answered, and a flag you were typed to receive could simply
+  be missing. After: every discovery response carries **every** flag, always a
+  boolean. A capability the host does not deliver is `enabled: false` — never an
+  absent key — so a client can read a flag without knowing whether it reached a
+  dispatcher, the REST endpoint, or anything else. `client.capabilities` no longer
+  asserts its own return type: it enumerates the spec's key list, so the type is
+  true by construction, and it reads a key an older server omits as `false`
+  (fail-closed, matching the wire rule).
+
+  **`@objectstack/spec`.** `WellKnownCapabilitiesSchema` becomes the one
+  vocabulary and gains the six flags that were previously the dispatcher's alone
+  (`websockets`, `files`, `analytics`, `ai`, `notifications`, `i18n`) — all six
+  were already real answers on the wire, so this declares them rather than
+  inventing them. `DiscoverySchema.capabilities` changes from an optional open
+  record to a **required closed object** derived from that vocabulary, one entry
+  per key. New exports: `WELL_KNOWN_CAPABILITY_KEYS` (the key list, derived from
+  the schema so nothing can hand-list a fourth dialect) and
+  `CapabilityDescriptorSchema` / `CapabilityDescriptor` (the `enabled` +
+  optional `features` / `description` entry shape, previously inline).
+
+  Required, not optional, is the `scoping` precedent read the other way round:
+  `scoping` is optional because only one producer can honestly answer it, whereas
+  every producer can answer `capabilities` — and an optional block would leave a
+  consumer back at `undefined` for every flag.
+
+  **Producers.** Each answers all thirteen keys from its own facts, with the basis
+  recorded per key in the code. The dispatcher now measures `comments` off the
+  `sys_comment` object in the registry it already resolves for its `/data` domain,
+  and `automation` / `cron` / `export` / `chunkedUpload` off the same service
+  predicates that gate its route advertisements. Its one honest `false` is
+  `transactionalBatch`: the atomic cross-object `/batch` route is mounted by
+  `@objectstack/rest`, and this dispatcher has no batch branch at all, so claiming
+  the runtime's `transaction()` here would advertise an endpoint the host does not
+  serve. `getDiscovery()` answers the six new flags off the service registry it
+  already reads, gated on serveability so a self-declared stub does not advertise
+  a capability it cannot back.
+
+  **Gates.** The three `discovery-schema-conformance.test.ts` suites built by
+  `#5682` and extended to `routes` by `#5743` gain a fullness criterion — every
+  vocabulary key present, every `enabled` a real boolean, no key outside the
+  vocabulary — with the allowance derived from the schema rather than written out.
+
+  **Upgrading.** A producer or fixture that builds a `DiscoverySchema`-shaped
+  document must now include a complete `capabilities` block; build it from
+  `WELL_KNOWN_CAPABILITY_KEYS` rather than by hand. Consumers need no change:
+  they receive strictly more keys than before, and any flag they already read
+  keeps its meaning. The lenient wire wrapper `GetDiscoveryResponseSchema` still
+  allows the block to be absent, so a response from an older server still parses.
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [b746aa0]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [d9971d3]
+- Updated dependencies [eb3e650]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [46365ab]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [c5adfe1]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/core@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Major Changes
diff --git a/packages/client/package.json b/packages/client/package.json
index bfa804bd77..137d369f4e 100644
--- a/packages/client/package.json
+++ b/packages/client/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/client",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "Official Client SDK for ObjectStack Protocol",
   "main": "dist/index.js",
diff --git a/packages/cloud-connection/CHANGELOG.md b/packages/cloud-connection/CHANGELOG.md
index 4bf6f757cf..1b7095f1b2 100644
--- a/packages/cloud-connection/CHANGELOG.md
+++ b/packages/cloud-connection/CHANGELOG.md
@@ -1,5 +1,364 @@
 # @objectstack/cloud-connection
 
+## 17.0.0-rc.4
+
+### Minor Changes
+
+- 28ad90e: feat(types,cloud-connection,lint,cli): ADR-0120 17.x 收尾 —— `isolated` 安装期姿态硬门(D5e)、D5c 重拼写 advisory、成文契约扫荡与三姿态 conformance (#5081)
+
+  ADR-0120 17.x 波的第三块,也是最后一块。前两块已在 main 上:#5212(driver 侧
+  D3+D4 —— `COALESCE(organization_id, '__global__')` 物化、drift 两侧同步、重复预检)
+  与 #5208(spec 词汇 `'organization'` + D5a/D5b lint)。本次补齐三件事:安装期的
+  姿态决策点、剩余的成文契约、以及把「一个 app 包跑遍三种姿态」从假设变成测试。
+
+  **D5e —— 装进 `isolated` 环境时的硬门。** 词汇本身是姿态无关的:作者说的是业务
+  边界(`'organization'` 一个组织一份 / `'global'` 整个安装一份),没有任何索引形状
+  读姿态。唯一的残留在一个方向上:`isolated` 下组织就是**不同客户**,此时 app 业务
+  对象上的 `'global'` 唯一既跨客户过度约束,又变成跨客户的存在性预言机(S10/S14)。
+  维护者裁定这是**硬门而非 advisory**:把带 `'global'` 唯一(非 `sys` 对象)的 app
+  装进 `isolated` 环境会**停下来并逐索引列出**,安装者(通常是 AI agent)要么确认它
+  确实是平台级的,要么改写为 `'organization'`;确认按 ADR-0104 attestation 风格
+  留痕在安装清单里(`InstalledManifestEntry.globalUniqueAttestation` —— 确认了什么、
+  谁确认的、何时、在哪个姿态下问的),**之后不复问**。
+
+  - 停下的安装**什么都不留**:先于 hot-register 和任何 ledger 写入,所以作者改完
+    元数据可以直接重试,不需要先卸载。
+  - 逐索引确认是有牙齿的:`confirmGlobalUniques` 收 `true` 或明确的 id 数组,只确认
+    其中一条仍会在剩下的那条上停住。
+  - 升级引入的**新**约束会被问,老的答案继续算数。
+  - 另一个姿态下给出的确认**不算同意** —— `isolated` 那个问题在 `single` 下从未被
+    问过,所以按「未确认」处理(唯一不会静默放行跨客户约束的方向)。
+  - ⛔ **永不做成启动期告警**(#4884 纪律)。boot 时的 rehydrate 不评估此门;门够不到
+    的两类存量 —— 门禁上线前的安装、装后姿态变更的环境 —— 由 `os doctor` 与
+    `os migrate plan` 的 advisory 形态覆盖。
+
+  判定里有三条是承重的,别「简化」掉:声明索引上的裸 `unique: true` **算**(D1 说它
+  就是 `'global'` 的位置式拼写,排除它等于让整个 17.x 可以靠拼写绕过);字段级
+  `true` **不算**(它是 `'organization'`,永久合法);`sys_`/`base_` 对象**不算**
+  (S5 那批引擎幂等键天然就是平台级的,每次安装都问一遍就是 #4884 的误报类)。
+
+  CLI: `os package install` 新增 `--confirm-global-uniques`,并把 409 渲染成可读的
+  逐条清单而不是一句 "Install failed (409)"。
+
+  **D5c —— 遗留手写组织复合索引的 advisory。** 新规则
+  `unique/legacy-organization-composite`:声明的唯一索引自己列出了组织列
+  (`{ fields: ['name','organization_id'], unique: true }`)—— 这是词汇出现之前手写
+  per-organization 的写法。它读起来像「每组织唯一」,物化出来却是普通复合索引,而
+  SQL UNIQUE 是 NULL-distinct 的:组织列为 NULL 的行上它**什么都不约束**(#5030),
+  在单组织部署上那就是每一行。改写成 `unique: 'organization'`(`fields` 原样保留,
+  driver 会把已列出的组织列**就地**变成 NULL-safe 形式)正是补上这个洞的动作。
+  **永远只是 advisory,永远不自动修**:老拼写永久合法、零强制 drift,而 opt-in 是
+  真实的物理收紧,要走 D4 的 `recreate_index` + 重复预检。
+
+  **D6 —— 成文契约扫荡。** `content/docs/data-modeling/indexing.mdx` 的
+  §Two ways to say "unique" 全节按新词汇重写(含 `os:check` 代码块);
+  `content/docs/protocol/objectql/schema.mdx` 的 §Uniqueness and tenancy 重写为
+  §Uniqueness and scope —— 其中那句「单租户部署不受影响,租户列是常量,复合索引
+  退化为单列索引」是 #5030 **证伪过的原话**,现已替换为 D3 的 NULL-safe 事实;
+  `content/docs/deployment/cli.mdx` 的 `replace_unique_index` / `recreate_index`
+  条目补上 NULL-safe 形状与重复预检;`content/docs/references/**` 经
+  `gen:schema && gen:docs` 再生成,未手改。
+
+  按 ADR-0120 Resolved #2 的非规范性引导(官方示例/脚手架/生成器在新代码中输出
+  显式拼写),`skills/objectstack-data/**` 的索引与校验规则整体扫过:声明索引一律
+  说清 scope,并新增一节完整讲 `'organization'` 的 NULL-safe 语义与「永远不写姿态」。
+  顺带修掉那里长期使用的 `tenant_id` —— 平台的列叫 `organization_id`。
+  `examples/**`、`create-objectstack` 模板与 `os generate` 经核查**根本没有声明任何
+  唯一约束**,故无可扫;这是核查结论,不是遗漏。
+
+  **三姿态 conformance(ADR §Acceptance tests)。** 同一个 fixture app 在
+  `single | group | isolated` 三姿态下启动,逐 S 行用**真实的违规插入**断言 enforcement
+  (S1/S2/S3/S4/S5/S6/S7/S8/S9/S11/S12),并逐姿态捕获物化出的索引键,断言三者
+  **逐字节相同** —— 「没有任何索引形状读姿态」这句话一旦有两者不同就是假的。相同性
+  断言配了一条正向断言(对着期望的键形状),这样「三次都什么都没建」不会读成「一致」。
+  外加 ADR 只要的那一条 transition smoke:在 `single` 下建库、`isolated` 下重新打开,
+  drift op 为零。
+
+  对既有部署的影响:除新增的安装期确认外,本次不改变任何已有物化行为。字段级
+  `unique: true` 一如既往合法。
+
+- 5a45b9b: `LocalManifestSource.read()` now says WHICH of the two things its `null` meant
+
+  `read()` answered `null` to two different questions at once — "this manifest was
+  never installed" and "it was installed, but its ledger file cannot be read" —
+  and dropped the reason for the second in an un-bound `catch`. Two admin
+  endpoints check `has()` first, so absence was already ruled out by the time they
+  called it, and both could only answer
+  `500 { code: 'MARKETPLACE_STORAGE_FAILED', message: 'Failed to read manifest cache.' }`:
+  a sentence whose only content is that the thing it just did failed, one line
+  after `has()` said the file is there. The `Unexpected end of JSON input` /
+  `EACCES` / `EISDIR` that names the repair had already been thrown away, and
+  nothing was written to the server log either.
+
+  **Breaking (`@objectstack/cloud-connection`):** `read()` returns an
+  `InstalledManifestLookup` instead of `InstalledManifestEntry | null`.
+
+  - FROM: `const entry = source.read(id);`
+  - TO: `const { entry, failure } = source.read(id);`
+
+  `entry` is the old return value unchanged, so a caller that legitimately treats
+  both nulls alike migrates by reading `.entry`. `failure` is a
+  `SkippedManifestEntry` — `{ file, cause }`, the same shape `list()` already
+  reports, with the thrown object carried unwrapped — and is present ONLY when a
+  ledger file exists and could not be read. `failure === undefined` with
+  `entry === null` therefore means "not installed", which is the distinction the
+  merged `null` erased. One new exported type, `InstalledManifestLookup`.
+
+  `read()` still does not validate the parsed value's SHAPE, and enumerating the
+  ledger directory still throws out of `list()` — both unchanged.
+
+  Consumer-visible behaviour:
+
+  - `POST /api/v1/marketplace/install-local/:manifestId/reseed-sample-data` and
+    `…/purge-sample-data` keep returning `500 MARKETPLACE_STORAGE_FAILED` — the
+    same failure, so a client branching on the code is unaffected — but the
+    message now names the ledger file to repair or remove and quotes the cause
+    verbatim, and a matching `warn` line goes to the server log.
+  - The install path's ADR-0120 D5e posture gate is unchanged on purpose: a
+    corrupt entry still counts as "no attestation on record", so the one-time
+    installation-wide-unique ceremony is asked again rather than skipped.
+
+- 7127b48: `LocalManifestSource.list()` now reports the ledger entries it could NOT read
+
+  A truncated, unreadable or unparseable file under
+  `.objectstack/installed-packages/` was skipped in an un-bound per-file `catch`
+  and `list()` returned a bare array, so a short list was indistinguishable from a
+  complete one — no difference in the return value, no log, no count. Three
+  consumers gave a confidently wrong answer: the installed app was never
+  registered at boot (gone from the app switcher, its objects nonexistent) with
+  nothing in the log, the console's installed-apps list came back short with
+  `success: true`, and `os doctor` printed `✓ Unique scope` over manifests it had
+  never parsed.
+
+  Skipping a corrupt file stays correct — one bad manifest must not stop a runtime
+  booting the packages that are fine. Skipping it _silently_ was the defect.
+
+  **Breaking (`@objectstack/cloud-connection`):** `LocalManifestSource.list()`
+  returns `{ entries, skipped }` instead of `InstalledManifestEntry[]`.
+
+  - FROM: `const entries = source.list();`
+  - TO: `const { entries, skipped } = source.list();`
+
+  `skipped` is `Array< { file: string; cause: unknown } >` — the file's basename
+  and the object reading or parsing it threw, unwrapped. Callers that only want
+  the old behaviour read `.entries`; the point of the shape is that dropping
+  `skipped` is now something a caller has to do on purpose. Two new exported
+  types, `InstalledManifestListing` and `SkippedManifestEntry`.
+
+  Enumerating the ledger DIRECTORY still throws out of `list()` — unchanged, and a
+  different fact from "some files in it would not parse".
+
+  `os doctor` reports unparseable entries as a `Unique scope` warning row naming
+  each file with its cause, and withholds the `✓` success line, alongside the
+  directory-level row it already had.
+
+### Patch Changes
+
+- 2ddba89: fix(tenancy): eight sites answered "is this deployment multi-org?" with the demoted `OS_MULTI_ORG_ENABLED` (#5262)
+
+  ADR-0105 D1 made `OS_TENANCY_POSTURE` the authoritative knob and demoted
+  `OS_MULTI_ORG_ENABLED` to a back-compat _input_ of `resolveTenancyPosture()`.
+  A deployment configured the documented way — `OS_TENANCY_POSTURE=isolated` (or
+  `group`), legacy boolean unset — therefore reads `false` from
+  `resolveMultiOrgEnabled()` while running a fully mounted organization wall.
+  #5233 corrected two sites in `plugin-auth`; a census found eight more, all
+  written before that function's doc comment was corrected. Third recurrence of
+  the shape (cloud#1020, #5233).
+
+  Each site was judged separately for **which** posture answers its question —
+  what the operator REQUESTED, or what the `tenancy` service reports is actually
+  IN FORCE — rather than converted mechanically:
+
+  - `objectql` `SchemaRegistry` — the env-derived multi-tenant default. Reads the
+    REQUESTED posture (it is constructed below the kernel, with no service
+    registry to ask). The `organization_id` column was always provisioned; what
+    diverged is its INDEX, so a posture-only deployment ran the Layer 0 wall's
+    hottest predicate unindexed while SecurityPlugin compiled that same wall.
+  - `plugin-dev` — whether to load the enterprise `@objectstack/organizations`.
+    REQUESTED posture, mirroring `serve.ts`: this branch is what mounts the wall,
+    so asking whether the wall is up would be circular. A posture-only dev stack
+    previously never loaded the package at all and served traffic unwalled. Its
+    diagnostic now names the posture that was requested instead of asserting
+    `OS_MULTI_ORG_ENABLED=true` at an operator who never set it.
+  - `runtime` `AppPlugin` (inline seed + hot-reload seeder) — EFFECTIVE posture,
+    via the `tenancy` service. These ask "will the per-org replay run instead of
+    me?", and on an ADR-0093 D5 degraded boot that replay does not exist, so
+    keying on the request would defer to a replay that can never happen. Walled
+    deployments previously inline-seeded exactly the NULL-organization rows the
+    code's own comment exists to avoid.
+  - `cloud-connection` marketplace local install (install-time seed + rehydrate
+    heal) — EFFECTIVE posture, same reasoning. The install path is a write path:
+    a walled deployment wrote every sample row with no `organization_id`, landing
+    the app's data outside the wall its own reads apply.
+  - `driver-sql` `isMultiTenantMode()` — REQUESTED posture (a driver has no
+    kernel to ask, and a suppressed warning is the costlier error for a
+    diagnostic). It also no longer memoises into `_multiTenantMode`: that froze a
+    process-level fact into a per-instance verdict on whichever write landed
+    first. The gate now resolves live, which is affordable because
+    `auditMissingTenant` consults it only after the `tenantId` early-out.
+  - `cli` `os verify` — REQUESTED posture. This one produced a green verification
+    run over an unverified property: a posture-only deployment silently skipped
+    every multi-tenant proof and exited 0.
+
+  **No configuration change is needed anywhere.** Deployments setting only
+  `OS_MULTI_ORG_ENABLED=true` keep working unchanged — `resolveTenancyPosture()`
+  falls back to it — and the `OS_TENANCY_POSTURE=isolated` + `OS_MULTI_ORG_ENABLED=true`
+  belt-and-braces configuration stays valid. Deployments that set only
+  `OS_TENANCY_POSTURE` can now drop the redundant boolean. Single-org behaviour is
+  unchanged at every site; only the knob each one reads is corrected.
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [da5d1b4]
+- Updated dependencies [d4e0809]
+- Updated dependencies [739f496]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [64cd010]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [9f747ee]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [43ca399]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [b746aa0]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [7bf3d1c]
+- Updated dependencies [db9c331]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [217b791]
+- Updated dependencies [fd8521f]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [18b8eaa]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [78adc2e]
+- Updated dependencies [81e2744]
+- Updated dependencies [277eb36]
+- Updated dependencies [41e605e]
+- Updated dependencies [2649ccb]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [a70cd0a]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [08f93bc]
+- Updated dependencies [d9971d3]
+- Updated dependencies [d9cac60]
+- Updated dependencies [eb3e650]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [02dc076]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [46365ab]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [c5adfe1]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [1203bb2]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [2ddba89]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [ef7845a]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [0cd08d5]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [5aaa6fc]
+- Updated dependencies [dca5bd3]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/runtime@17.0.0-rc.4
+  - @objectstack/types@17.0.0-rc.4
+  - @objectstack/core@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Patch Changes
diff --git a/packages/cloud-connection/package.json b/packages/cloud-connection/package.json
index 042c52066a..56dd71daf8 100644
--- a/packages/cloud-connection/package.json
+++ b/packages/cloud-connection/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/cloud-connection",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "Runtime-side client for an ObjectStack cloud control plane — marketplace browse proxy, install-local, device-code binding, org catalog and installed views, and the /api/v1/runtime/config discovery endpoint. Open mechanism (ADR-0008): the hub service, plan policy, and entitlements stay server-side.",
   "type": "module",
diff --git a/packages/connectors/connector-mcp/CHANGELOG.md b/packages/connectors/connector-mcp/CHANGELOG.md
index 00e7d31023..d81c4843fa 100644
--- a/packages/connectors/connector-mcp/CHANGELOG.md
+++ b/packages/connectors/connector-mcp/CHANGELOG.md
@@ -1,5 +1,134 @@
 # @objectstack/connector-mcp
 
+## 17.0.0-rc.4
+
+### Patch Changes
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [b746aa0]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [d9971d3]
+- Updated dependencies [eb3e650]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [46365ab]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [c5adfe1]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/core@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Patch Changes
diff --git a/packages/connectors/connector-mcp/package.json b/packages/connectors/connector-mcp/package.json
index 8ad752b1e8..0d64d1ad19 100644
--- a/packages/connectors/connector-mcp/package.json
+++ b/packages/connectors/connector-mcp/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/connector-mcp",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "Model Context Protocol (MCP) connector for ObjectStack — a generic adapter that turns any MCP server's tools into a connector's actions on the automation engine's connector registry (ADR-0024).",
   "main": "dist/index.js",
diff --git a/packages/connectors/connector-openapi/CHANGELOG.md b/packages/connectors/connector-openapi/CHANGELOG.md
index d75d81363c..3ec8761426 100644
--- a/packages/connectors/connector-openapi/CHANGELOG.md
+++ b/packages/connectors/connector-openapi/CHANGELOG.md
@@ -1,5 +1,134 @@
 # @objectstack/connector-openapi
 
+## 17.0.0-rc.4
+
+### Patch Changes
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [b746aa0]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [d9971d3]
+- Updated dependencies [eb3e650]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [46365ab]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [c5adfe1]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/core@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Patch Changes
diff --git a/packages/connectors/connector-openapi/package.json b/packages/connectors/connector-openapi/package.json
index e865ed7972..b4b724f2ac 100644
--- a/packages/connectors/connector-openapi/package.json
+++ b/packages/connectors/connector-openapi/package.json
@@ -1,6 +1,6 @@
 {
     "name": "@objectstack/connector-openapi",
-    "version": "17.0.0-rc.3",
+    "version": "17.0.0-rc.4",
     "license": "Apache-2.0",
     "description": "OpenAPI 3.x connector generator for ObjectStack — turns a declarative OpenAPI document into connector actions on the automation engine's registry, with a self-contained static-auth HTTP transport (ADR-0023).",
     "main": "dist/index.js",
diff --git a/packages/connectors/connector-rest/CHANGELOG.md b/packages/connectors/connector-rest/CHANGELOG.md
index b4d56fd491..43e2c04e91 100644
--- a/packages/connectors/connector-rest/CHANGELOG.md
+++ b/packages/connectors/connector-rest/CHANGELOG.md
@@ -1,5 +1,134 @@
 # @objectstack/connector-rest
 
+## 17.0.0-rc.4
+
+### Patch Changes
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [b746aa0]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [d9971d3]
+- Updated dependencies [eb3e650]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [46365ab]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [c5adfe1]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/core@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Patch Changes
diff --git a/packages/connectors/connector-rest/package.json b/packages/connectors/connector-rest/package.json
index 70332a758a..c7552f468b 100644
--- a/packages/connectors/connector-rest/package.json
+++ b/packages/connectors/connector-rest/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/connector-rest",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "Generic REST connector for ObjectStack — the reference concrete connector that registers a `request` action on the automation engine's connector registry (ADR-0018 §Addendum).",
   "main": "dist/index.js",
diff --git a/packages/connectors/connector-slack/CHANGELOG.md b/packages/connectors/connector-slack/CHANGELOG.md
index a7606d52a7..4031ba9bf7 100644
--- a/packages/connectors/connector-slack/CHANGELOG.md
+++ b/packages/connectors/connector-slack/CHANGELOG.md
@@ -1,5 +1,134 @@
 # @objectstack/connector-slack
 
+## 17.0.0-rc.4
+
+### Patch Changes
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [b746aa0]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [d9971d3]
+- Updated dependencies [eb3e650]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [46365ab]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [c5adfe1]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/core@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Patch Changes
diff --git a/packages/connectors/connector-slack/package.json b/packages/connectors/connector-slack/package.json
index c5282f741b..b50b73c5dc 100644
--- a/packages/connectors/connector-slack/package.json
+++ b/packages/connectors/connector-slack/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/connector-slack",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "Slack Web API connector for ObjectStack — registers `chat.postMessage` / `chat.update` / `call` actions on the automation engine's connector registry (ADR-0018 §Addendum, ADR-0022).",
   "main": "dist/index.js",
diff --git a/packages/console/CHANGELOG.md b/packages/console/CHANGELOG.md
index acefab5af9..7486026ccf 100644
--- a/packages/console/CHANGELOG.md
+++ b/packages/console/CHANGELOG.md
@@ -1,5 +1,80 @@
 # @objectstack/console
 
+## 17.0.0-rc.4
+
+### Minor Changes
+
+- ce1155c: Console (objectui) refreshed to `f995a452d2ca`. Frontend changes in this range:
+
+  Derived from the changesets objectui declared over the range — 64 releasing of 65 changesets added across 98 non-merge commits; omitted: 1 release-nothing changeset, 33 commits carrying no changeset (they ship no package code).
+
+  - **minor** — The record detail page now shows a read-gated approval panel (#3461). A record in approval used to expose NOTHING about the running approval to anyone but the current pending appr… (objectui `5af285210`)
+  - **minor** — `DrillDownConfig` now declares only keys a renderer reads, and `target: 'navigate'` is honoured on charts too (#3354). (objectui `9e9e9a92f`)
+  - **minor** — Console chrome i18n gaps (objectstack#5407). (objectui `3889ffb4c`)
+  - **minor** — The console language choice now survives a reload. `I18nProvider` writes every language change to `localStorage` (`objectui-locale`, exported as `LOCALE_STORAGE_KEY`) and boots th… (objectui `0554e889c`)
+  - **minor** — `<ObjectChart>` declares `drillDown` as a registry input, so the SDUI save gate treats the segment drill as a contract prop instead of an unknown one (framework#5022). (objectui `524a6357b`)
+  - **minor** — The environment entitlement dialog now reads its context from `error.details.*` — the single declared location — and the flat dual-dialect tolerance is deleted (objectui#3329, the… (objectui `8ec406728`)
+  - **minor** — `@object-ui/core` now ships the server-action dispatcher factory — `createServerActionHandler({ fetch, baseUrl, resolveObject, ... })` — so any consumer of the runner (standalone… (objectui `5781fb15a`)
+  - **minor** — `AppSchemaRenderer` now derives area visibility from the items inside the area, closing the visible-but-empty regression the spec 17.0.0 area-key retirement left behind (objectui#… (objectui `608669eb5`)
+  - **minor** — Track `@objectstack/spec` 17.0.0-rc.2 (objectui#3235, #3208, #3287, #3264). (objectui `d22ae31ce`)
+  - **minor** — Field widgets no longer spread renderer-only props — or arbitrary keys from a field config — onto the DOM element they render (objectui#3291). (objectui `19b8c9be3`)
+  - **minor** — `RichTextField` honours `mobile_fullscreen`, so `mobile.fullscreenLongText` is finally true of rich text too (objectui#3301). (objectui `30ae33a77`)
+  - **minor** — `mobile.fullscreenLongText` finally reaches auto-generated long-text fields, and `mobile_fullscreen` gets one declared carrier (objectui#3245). (objectui `f44d8727f`)
+  - **minor** — **BREAKING (v17)** — The flow designer writes node geometry as the spec's `FlowNode.position`, not its own `ui: { x, y }` (objectui#3172). (objectui `6e794a19e`)
+  - **minor** — **BREAKING (v17)** — field widgets receive their metadata on ONE key, `field`. `schema` is removed from the widget contract (objectui#3233). (objectui `042e09d77`)
+  - **patch** — `UserFilters` no longer carries its own operator table when it lowers a `ViewTab.filter` preset into an ObjectQL AST node. The private `specOperatorToAst` was the second hand-kept… (objectui `d7f350a89`)
+  - **patch** — Name `CommentThread`'s three emoji-only buttons, and follow the session language past the 7-day mark (objectui#3441) (objectui `65516ba4a`)
+  - **patch** — `toFilterNode` now lowers a spec `ViewFilterRule[]` into ObjectQL AST nodes instead of returning the array verbatim, so a saved view's stored filter reaches `$filter` as something… (objectui `2a9513d81`)
+  - **patch** — Localize the create / edit / view form title `ObjectView` builds itself (objectui#3462) (objectui `28b2e6571`)
+  - **patch** — Localize the record-detail headings that `ObjectKanban`, `ObjectTree` and `ObjectView` build themselves (objectui#3459) (objectui `aa36e6073`)
+  - **patch** — Localize the record-detail overlay heading that `ListView` and `ObjectGrid` build themselves (objectui#3426) (objectui `61958416e`)
+  - **patch** — The close button that the `Sheet` and `Dialog` primitives auto-render now announces itself in the session locale instead of always in English. Both buttons are icon-only (a lucide… (objectui `71be40696`)
+  - **patch** — Localize `PresenceAvatars` — the avatar stack's accessible name and tooltips follow the session language (objectui#3440) (objectui `ca0fa8fab`)
+  - **patch** — `PageRenderer` no longer renders its own `<h1>` when the page authors a titled `page:header`, so a page has exactly one level-1 heading. Every non-record page used to render the p… (objectui `06632e9d1`)
+  - **patch** — Localize `@object-ui/collaboration` — `CommentThread` no longer hardcodes English (objectstack#5506) (objectui `94c5b7c4e`)
+  - **patch** — `TextAreaField`'s fullscreen edit dialog now gives screen reader users the character count it has always shown sighted ones. The dialog's footer counter was a bare `{n}/{max}` spa… (objectui `f789c3b3a`)
+  - **patch** — `ObjectDataPage`'s "Save as view" now folds the active URL drill conditions into `@objectstack/spec` `ViewFilterRule`s before persisting them, instead of writing the runtime filte… (objectui `875c5fafb`)
+  - **patch** — Localize `RecordDetailDrawer`'s drag-resize handle (objectstack#5733) (objectui `5a24ad9cb`)
+  - **patch** — The record picker's filter panel now sends the AUTHORED value of a picked `select` filter option instead of the control's stringified form. Radix `Select` speaks strings — options… (objectui `34d9169f6`)
+  - **patch** — Localize the record-overlay and tab-badge chrome that #5430's sweep left behind (objectstack#5506) (objectui `5dd012776`)
+  - **patch** — The lookup "Browse all records" Record Picker's filter panel now offers the options a `select` field declares in its schema (objectui#3336). `LookupField` turns each typed picker… (objectui `5881a2cc4`)
+  - **patch** — `TextAreaField`'s character counter no longer re-announces itself on every keystroke. Measured on `main` in a zh session with `maxLength: 500`, typing a 52-character sentence one… (objectui `789fe3ee2`)
+  - **patch** — Fix matrix report cells showing another bucket's numbers when dimension values run together. (objectui `509104a1b`)
+  - **patch** — Fix dataset pivot cells showing another row's numbers when a dimension value contains a space. (objectui `ce7cbe5af`)
+  - **patch** — Give `InlineCreateRelated`'s card-header close button an accessible name (objectui#3411 — the neighbouring defect found while implementing #3381/PR #3410, in the same file and lef… (objectui `58a00f0b4`)
+  - **patch** — Give `InlineCreateRelated`'s "Link Existing" search box a real accessible name (objectui#3381 — the neighbouring defect found while implementing #3341/PR #3380, and left out of th… (objectui `b17ce4c25`)
+  - **patch** — `TextAreaField`'s character counter now announces itself in the session locale. The counter block — rendered only when the field declares `maxLength` — carried the accessible name… (objectui `2409e1d04`)
+  - **patch** — fix(fields): translate the registered path's fullscreen long-text dialog (objectui#3404) (objectui `6fe485bf2`)
+  - **patch** — `TextAreaField` / `RichTextField` now honour `disabled` on their fullscreen editing path. `disabled` used to reach the inline control only: `showFullscreenButton` never consulted… (objectui `7d08c3feb`)
+  - **patch** — The form renderer's built-in `textarea` branch now honours `readonly` / `disabled` on its fullscreen exit, which previously bypassed both (objectui#3400). `renderFieldComponent` d… (objectui `fd54c3e7a`)
+  - **patch** — 表单内置 `textarea` 的全屏编辑对话框现在能拿到字段自己的 label：对话框标题显示字段名而不是恒定的通用词「编辑文本」，同一张表单上多个长文本字段的展开按钮也终于有了互不相同的无障碍名（objectui#3393）。 (objectui `85c4c9ce0`)
+  - **patch** — The form renderer's built-in `textarea` branch reads the fullscreen long-text flag on one spelling (objectui#3303). (objectui `9cbcbf478`)
+  - **patch** — The form renderer's last user-visible English literals now go through i18n (#3272). The fullscreen long-text editor (`mobile_fullscreen`) was an entire untranslated dialog — title… (objectui `4eeb932aa`)
+  - **patch** — Localize the last untranslated console-chrome accessible names (objectstack#5430) (objectui `b71fc92f3`)
+  - **patch** — `ObjectGantt`'s quick-filter bar is now localized instead of pinned to Chinese. The four `QuickFilterBar` labels (`all`, `clear`, `empty`, `resultSummary`) were hardcoded as Chine… (objectui `5c856ecb5`)
+  - **patch** — Associate the label with its control at the two form surfaces where the two were never programmatically connected (objectui#3341 — found while implementing #3299/PR #3340, and del… (objectui `53811d179`)
+  - **patch** — `ActionEngine.getActionsForLocation` now evaluates a `{ dialect: 'cel', source }` action `visible` predicate on the canonical `@objectstack/formula` engine instead of the legacy J… (objectui `18cd43289`)
+  - **patch** — Settings pages read the declared `{ success, data }` response envelope, so the whole Setup → Configuration section works again against a framework#3843 server (objectui#3366). (objectui `7d0c6de39`)
+  - **patch** — The flow designer no longer seeds new `wait` nodes with the retired `waitEventConfig.onTimeout` (objectui#3316). (objectui `35da149c5`)
+  - **patch** — Gallery covers now resolve the `coverField` value through its **file value shape** instead of assuming the field value _is_ a URL string, so an ADR-0104-conforming `image` value r… (objectui `978705c8f`)
+  - **patch** — The list toolbar's "Filter" now saves. Saving a filter from the runtime toolbar PUT the FilterBuilder's whole group object (`{ id, logic, conditions }`) into the view's `filter`,… (objectui `68b6a2855`)
+  - **patch** — The lookup "Browse all records" Record Picker now formats its columns with the same field metadata the list view uses (objectui#3333). Previously the dialog handed cell renderers… (objectui `9bc3709b9`)
+  - **patch** — Behavior change — **an authored display `type` can NARROW inline editability, but never WIDEN it** (objectui#3355). (objectui `bbbde1207`)
+  - **patch** — `record:highlights` now honours a `readonly: true` on an authored field entry, so a header chip for a platform-owned column no longer offers inline edit. `HeaderHighlight`'s edita… (objectui `23018cc03`)
+  - **patch** — Deliver the required state to the control in the five renderers outside the object form that still painted it as an asterisk only (objectui#3299 — the same defect #3290/#3298 fixe… (objectui `532cf8b9e`)
+  - **patch** — The Combobox trigger now declares `type="button"` explicitly, so it can never submit an enclosing `<form>` (objectui#3344). The current Radix `PopoverTrigger` happens to supply `t… (objectui `34595eb45`)
+  - **patch** — `TagsField` no longer ships a hardcoded Chinese input placeholder (objectui#3342, AGENTS.md Commandment #-1). The placeholder now resolves through the pinned chain: the author-dec… (objectui `c7ed4c366`)
+  - **patch** — AddressField / GeolocationField sub-inputs now derive their DOM ids from a `useId()` prefix + sub-field name (the RadioField / CheckboxesField `groupId` paradigm) instead of hardc… (objectui `b7165ce47`)
+  - **patch** — 20 more registered field widgets now announce a failed validation to assistive tech: `multiselect`, `radio`, `checkboxes`, `tags`, `lookup`, `master_detail`, `user`, `owner`, `fil… (objectui `8d8094a7c`)
+  - **patch** — `field:permission-facet-link` now registers through `withFieldCarrier` — the repo's only raw `field:` registration bypassed the single-metadata-carrier seam (objectui#3233), so un… (objectui `c7fba276e`)
+  - **patch** — The console server-action wrapper's `opensInNewTab` choreography no longer ships hard-coded bilingual Chinese/English copy (objectui#3321, AGENTS.md Commandment #-1): the pre-open… (objectui `a41568462`)
+  - **patch** — `AppSidebar` and `UnifiedSidebar` area switchers now adopt the derived area visibility introduced for `AppSchemaRenderer` in objectui#3311, closing the same visible-but-empty gap… (objectui `8d9984c2e`)
+  - **patch** — RecordDetailView's `type:'modal'` dispatch no longer falls back to the server-side action handler when the target resolves to neither a page nor an object. That fallthrough could… (objectui `94755bb88`)
+  - **patch** — `field:select` now announces its validation state to assistive tech: the widget's DOM pass-through lands on the Radix `SelectTrigger` — the focusable `<button role="combobox">` a… (objectui `49f7449f9`)
+  - **patch** — The required state now reaches the input control as `aria-required`, instead of existing only as part of the control's accessible name (objectui#3290). (objectui `680080ada`)
+
+  objectui range: `f5bc4c78be76...f995a452d2ca`
+
 ## 17.0.0-rc.2
 
 ### Minor Changes
diff --git a/packages/console/package.json b/packages/console/package.json
index ab163aec84..4da08cae69 100644
--- a/packages/console/package.json
+++ b/packages/console/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/console",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "description": "Prebuilt Console SPA pinned to this @objectstack/framework release. Source of truth: @object-ui/console (https://github.com/objectstack-ai/objectui).",
   "license": "Apache-2.0",
   "homepage": "https://github.com/objectstack-ai/objectstack/tree/main/packages/console",
diff --git a/packages/core/CHANGELOG.md b/packages/core/CHANGELOG.md
index bca48ab174..0e1071dbcc 100644
--- a/packages/core/CHANGELOG.md
+++ b/packages/core/CHANGELOG.md
@@ -1,5 +1,507 @@
 # @objectstack/core
 
+## 17.0.0-rc.4
+
+### Major Changes
+
+- 29c6c9d: feat(spec,core,runtime)!: declarative `apis:` refuses loudly instead of parsing into silence; the `ApiRegistry` family retires (#4936, #4939)
+
+  The declarative API-endpoint surface was **zero-execution end to end**, and said nothing
+  about it. Metadata loading worked perfectly — a stack declared `apis:`, `defineStack`
+  accepted it, and `GET /api/v1/meta/api` returned every endpoint with every key intact.
+  The execution side never fired once. On a real boot (showcase, 47 plugins) both declared
+  paths answered a bare `404 {"error":"Not found"}` — not even the dispatcher's semantic
+  404, because **no route was ever mounted** for a declared path, so the request died at
+  Hono's `notFound`. Behind that, the dispatcher's `handleApiEndpoint` branch resolved the
+  metadata service and called `matchEndpoint` on it — a method **no implementation in the
+  repo has ever provided**. The branch returned "not handled" on every request ever served.
+
+  So every key on `ApiEndpointSchema` was declared ≠ enforced: `path`/`method` (never
+  mounted), `type`/`target`/`objectParams` (never executed), `cacheTtl`,
+  `inputMapping`/`outputMapping`, `rateLimit`, `summary`/`description` — and
+  **`authRequired`**, a security semantic that parsed green and gated nothing at all. That
+  is false compliance, the failure ADR-0049 exists to stop, not debt.
+
+  ## BREAKING — a non-empty `apis:` is now rejected
+
+  Metadata that parsed cleanly before is now **refused at publish/validate**, with the
+  prescription in the rejection itself:
+
+  ```
+  apis: `apis:` (declarative ApiEndpoint) is DECLARED BUT NOT EXECUTABLE in this runtime,
+  so a non-empty array is rejected instead of silently accepted (#4936). …
+  ```
+
+  **FROM → TO.** `apis: [ …endpoints… ]` → `apis: []` (or delete the key; both are still
+  accepted, and an empty array is not a special case). To actually serve the route today,
+  mount it **in code** — a plugin manifest `contributes.routes` entry, or an `http.server`
+  route. That is now the only honest path, and the one `examples/app-showcase` uses
+  (`src/system/server/recalc-endpoint.ts`).
+
+  The refusal lives on `ObjectStackDefinitionSchema` itself, which is the single choke
+  point every path runs through — `defineStack`, the metadata plugin's artifact ingestion,
+  `os validate`, the lint scorer and `EnvironmentArtifactSchema`. There is no path that
+  forgot to check.
+
+  **The `ApiEndpoint` vocabulary is deliberately KEPT.** Retiring it was considered and
+  rejected: endpoint shapes are an industry-stable form, so a retirement would only mean
+  re-introducing the identical schema later. Your endpoint definitions stay valid TypeScript
+  and stay in the spec; only _authoring them into a stack_ is refused, and only until the
+  executor lands. Keep them commented next to your stack — that is what the showcase does.
+  The executor (route mounting + endpoint matching + per-key wiring for
+  `authRequired`/`cacheTtl`/`inputMapping`/`outputMapping`/`rateLimit`) is tracked by
+  **#5040**, which replaces this rejection with real execution.
+
+  ## BREAKING — the `ApiRegistry` / `ApiEndpointRegistration` family is removed (#4939)
+
+  The repo carried a **second**, unrelated declaration shape for "an API endpoint":
+  `ApiEndpointRegistrationSchema` and the ~500-line `ApiRegistry` service that
+  `createApiRegistryPlugin()` registered under `api-registry`. Nothing composed it — every
+  assembly site lived in `packages/core/examples/`, with no registration in
+  `packages/runtime`, `packages/cli` or any `examples/app-*`, and a real boot carried no
+  such service. The whole family was therefore inert, including
+  `ApiEndpointRegistration.requiredPermissions`, whose docs promised **in the present tense**
+  that "the gateway layer automatically validates these permissions" while no gateway read
+  it. Two declaration shapes, both dead; this retirement converges them on one.
+
+  Removed from `@objectstack/spec/api`: `ApiEndpointRegistration(Schema)`,
+  `ApiRegistry(Schema)`, `ApiRegistryEntry(Schema)`, `ApiMetadataSchema`,
+  `ApiParameterSchema`, `ApiResponseSchema`, `ApiDiscoveryQuerySchema`,
+  `ApiDiscoveryResponseSchema`, `ApiProtocolType`, `HttpStatusCode`,
+  `ObjectQLReferenceSchema`, `SchemaDefinition` (12 JSON-Schema defs, 67 authorable keys).
+  Removed from `@objectstack/core`: `ApiRegistry`, `createApiRegistryPlugin`.
+  Removed from `@objectstack/plugin-hono-server`: the `useApiRegistry` option — it was
+  defaulted to `true` and read by nothing, configuring a service that was never composed.
+
+  **FROM → TO.** There is no replacement shape to migrate to, because nothing executed the
+  old one: delete the registration objects. If you were assembling an `ApiRegistryEntry`,
+  you were building a value only your own code read — keep it as your own type. Declarative
+  endpoints have one vocabulary now, `ApiEndpointSchema`.
+
+  `ConflictResolutionStrategy` **survives** the removal and moved to
+  `@objectstack/spec/api`'s `router.zod` — same name, same four values
+  (`error`/`priority`/`first-wins`/`last-wins`), same import path. It is pinned there by two
+  independent ratchets and is not part of the retired surface.
+
+  ## Also in this change
+
+  - **BREAKING (`@objectstack/runtime`):** `HttpDispatcher.handleApiEndpoint()` is deleted,
+    along with its now-orphaned private `callData` delegate, and `/__api-endpoint` leaves
+    `LEGACY_CHAIN_PREFIXES` and the route ledger. The method was public, so this is an API
+    removal — but it returned `{ handled: false }` for every call it ever received, so no
+    caller can observe a behaviour change beyond the missing symbol. Delete the call.
+    Absence is now loud (ADR-0076): the surface is refused at authoring rather than 404ing
+    at runtime with dead code behind it.
+  - `examples/app-showcase` no longer declares endpoints, and its coverage manifest no
+    longer claims the capability is `demonstrated` — that entry read "executed by the runtime
+    dispatcher (handleApiEndpoint)", which was exactly the advertise-what-you-don't-deliver
+    claim Prime Directive #10 forbids.
+  - The endpoint-level `rateLimit` tracking pointers left by #4910/#5006 now name **#5040**,
+    the live executor card, instead of #4936, which closes with this change.
+
+### Minor Changes
+
+- 0f2fdcd: fix(core)!: a throwing `kernel:bootstrapped` / `kernel:listening` handler fails the boot on LiteKernel too (#5257)
+
+  **A failed `listen()` no longer yields a false "✅ Bootstrap complete".**
+
+  #5170 (PR #5258) unified `kernel:ready`: a handler that throws fails the boot on
+  `ObjectKernel` and `LiteKernel` alike. It deliberately ruled that one hook only,
+  leaving the other lifecycle hooks split — `ObjectKernel` propagates their
+  failures (its `context.trigger` is a bare awaited loop that never catches) while
+  `LiteKernel` routed them through the isolating dispatcher, logging
+  `Hook handler failed: <name>` and carrying on. This closes the two boot-path
+  hooks that were left: `kernel:bootstrapped` and `kernel:listening` now use the
+  propagating dispatcher (`triggerHookOrThrow`) on `LiteKernel`, in the same shape
+  #5258 established — the remaining handlers for that hook are skipped, the later
+  boot hooks never fire, the original error reaches the caller **unwrapped**,
+  `state` is left `'stopped'` rather than `'running'`, and the success line is
+  never logged.
+
+  The concrete failure this removes: `HonoServerPlugin` opens its socket inside a
+  `kernel:listening` handler — `await this.server.listen(port)`, with no try/catch
+  of its own, deliberately. When that rejected on `LiteKernel` (EACCES on a
+  privileged port, a failure inside the port-fallback logic itself, a serverless /
+  edge host where `listen` is not available at all) the throw was swallowed,
+  `bootstrap()` resolved normally, and the process printed
+  `✅ Bootstrap complete` while **nothing was listening**. The same plugin code on
+  `ObjectKernel` failed the boot. The health check that came next was the first
+  thing to notice, and it had already been told startup succeeded. Plain "port is
+  in use" was never affected — `server.listen` falls back to a random port
+  internally — which is exactly why this stayed invisible.
+
+  `kernel:bootstrapped` carries reconcile and audit work (objectql's
+  `announceOpenMigrationGates`, service-automation's node-type / trigger-binding
+  audits, the sharing plugin's boot backfills); a swallowed failure there is a
+  quieter version of the same lie — the audit silently does not run.
+
+  **`kernel:shutdown` keeps fail-soft dispatch**, now as an explicit per-hook
+  judgement recorded in a comment at the dispatch site rather than an inherited
+  default. On the teardown path there is no "refuse to proceed" left to buy, and
+  the handlers queued behind a failing one — plus the reverse-order `destroy()`
+  pass after them — are what flush buffers, close connections and release locks.
+  Aborting that sequence would convert one bad handler into leaked resources and
+  unflushed writes.
+
+  **Who is affected.** Hosts that boot through `LiteKernel` — vitest, serverless,
+  edge (Workers) — and register a `kernel:bootstrapped` or `kernel:listening`
+  handler that can throw. Such a host previously came up "successfully" with the
+  work of that handler silently skipped; it now refuses to start and surfaces the
+  original error. If a handler of yours performs best-effort work whose failure
+  genuinely must not stop the boot, it needs its own `try/catch` — which is what
+  the in-repo `kernel:bootstrapped` subscribers already do, per handler, with the
+  reason written down. Nothing in this repo relied on the swallow: the core (426),
+  client, runtime, http-conformance, connector-{rest,mcp,slack} and
+  service-automation (665) suites pass unchanged.
+
+  Boot assertions still belong in `kernel:ready`: it is the earliest hook at which
+  the service registry is finished filling.
+
+- 8ffa8b9: fix(core)!: a throwing `kernel:ready` handler now fails the boot on **LiteKernel** too (#5170)
+
+  **Behaviour change — read this if you run `LiteKernel` (vitest harnesses,
+  serverless functions, edge workers).** A `kernel:ready` handler that throws now
+  **rejects `bootstrap()`** on `LiteKernel`, exactly as it always has on
+  `ObjectKernel`. Before this change the throw was caught inside the kernel,
+  written out as one `Hook handler failed: kernel:ready` error log, and the boot
+  continued to "✅ Bootstrap complete".
+
+  **Why it mattered.** The two kernels ran the same hook through two different
+  dispatchers: `ObjectKernel` used `context.trigger` (a bare awaited loop that
+  never catches), `LiteKernel` used `triggerHook` (per-handler try/catch,
+  "continue with other handlers even if one fails"). Same hook name, same plugin
+  code, opposite failure semantics — which is `declared ≠ enforced` in the
+  kernel's own lifecycle contract.
+
+  `kernel:ready` is the only correct moment for a plugin to assert that a
+  precondition it _declared_ was actually delivered: the service registry is
+  still filling during `init()`, so a boot gate has nowhere earlier to run. Every
+  "declare it and we refuse to start if we cannot honour it" gate in this repo
+  therefore lives there — and on `LiteKernel` those gates were being downgraded to
+  a log line while the process came up and served traffic without the guarantee it
+  had announced. `EmailServicePlugin`'s `queueDelivery: true` gate (#5160) is the
+  worked example: on `ObjectKernel` the boot failed, on `LiteKernel` the server
+  came up and quietly fell back to inline delivery. Serverless is exactly where
+  "do not start misconfigured" matters most.
+
+  **Who is affected.** Any `LiteKernel` host whose `kernel:ready` handler throws
+  on a healthy boot. That boot previously "succeeded"; it now fails loudly with
+  the original error, and the kernel is left `stopped` rather than `running`. The
+  failure was never silent — it was already an `ERROR` line in your logs — so
+  check for `Hook handler failed: kernel:ready` in existing logs to find hosts
+  that will now refuse to start. If the handler's work is genuinely optional,
+  catch inside the handler and log there; the kernel no longer decides that for
+  you. The full test surface in this repo that boots `LiteKernel` (core, client,
+  runtime, http-conformance, the connectors, service-automation) passes unchanged
+  — nothing was relying on the swallow.
+
+  Scope: **`kernel:ready` only.** `kernel:bootstrapped`, `kernel:listening` and
+  `kernel:shutdown` keep `LiteKernel`'s isolating dispatch, pinned by a test.
+
+### Patch Changes
+
+- b746aa0: fix(service-automation): connector 物化失败的软路径改用结构化 `meta`;顺带修好 `ObjectLogger.error` 丢弃契约第三参的缺陷 (#5575)
+
+  ## service-automation:`fail(msg, cause)`
+
+  `reconcileDeclaredConnectors` 的报错器有两条路径(ADR-0097):冷启动 `throw`(fatal),
+  `metadata:reloaded` 之后 —— Studio publish、`os dev` 重编译 —— 记日志并让旧 connector
+  继续服务(soft)。其中两个调用点把**外来**的 `err.message` 插进那条日志 message:
+  `resolveInstanceAuth` 失败处,以及 provider factory 抛错处。这两个 message 都不是我们
+  自己的:credential resolver 由宿主提供
+  (`AutomationServicePluginOptions.credentialResolver`),provider factory 更是 ADR-0097
+  明确鼓励第三方去写的代码 —— 第一个用严格 Zod schema 校验 `providerConfig` 的 factory
+  抛出的就是 `ZodError`,它的 `.message` 是 issue 数组的多行 JSON dump,第一行是一个 `[`。
+
+  `ObjectLogger` 每次调用只写一条 `<ts> <LEVEL> <msg>` 记录,带换行的 message 会溢出到
+  不带等级头的后续物理行,于是运行时 stderr 的每一个按行工作的消费者 —— 文件 sink、
+  `docker logs`/journald 送进日志采集、一次 `grep ERROR` —— 都会把那些续行读成无法归属的
+  垃圾记录:一条诊断散成 N 个碎片。与 #5048 在 flow 绑定接缝上是同一类,也是同一条 #4632
+  原则:被搅烂的诊断比没有诊断更贵。
+
+  改法与 PR #5572 同源:`fail(msg, cause?)` —— message 是不含换行的自足句子,cause 按路径
+  分别渲染。soft 路径把 cause 交给 logger 的**结构化 meta**(`issues[]` / `error`);fatal
+  路径把 cause 文本接在抛出的 message 后面(`… cause: <text>`),因为 throw 不是日志记录,
+  内核失败通道原样打印,多行 ZodError dump 在终端里本来就好读 —— 同一个 cause,两种受众,
+  刻意不共用一种形状。`#5048` 引入的内部模块随之从 `flow-bind-diagnostics.ts` 更名为
+  `thrown-cause-diagnostics.ts`(`describeThrownForLog`),因为它从来不是 flow 专属的:
+  主题是日志管线,不是 metadata 类型。被拒键名仍放在 `unrecognized` 而不是 Zod 原本的
+  `keys`(`ObjectLogger` 的脱敏表按子串匹配,`keys` 含 `key`)。
+
+  **一处订正**:#5575 的 issue 正文把此处的危害归给了 `serve` 的启动诊断缓冲
+  (`BootLogCapture`)。那个缓冲看不到这条路径 —— `ObjectLogger` 把 `warn` 送 stdout(启动
+  静默窗口只包了 `process.stdout.write`),`error`/`fatal` 送 **stderr**,而且 soft 路径在
+  `metadata:reloaded` 之后才跑,窗口早已恢复。危害是上面那串按行消费者,以及日志查询根本
+  无法按字段过滤;机制写进了模块文档,连同 `warn`/`error` 下游不同这件事本身。
+
+  ## core:`ObjectLogger.error`/`fatal` 兑现契约声明的 `meta`
+
+  `Logger` 契约声明 `error(message, error?: Error, meta?)`。`ObjectLogger` 按形状分派,
+  所以 meta 也允许出现在 `error` 位 —— 这份宽容没问题;**丢掉一个自己声明的参数**有问题:
+  `error === undefined` 时旧代码走 `write(level, message, errorOrMeta)`,第三个参数从未被
+  读取。于是每一个按契约书写的 `logger.error(msg, undefined, { … })` 都只输出一条裸 message,
+  事实全部静默消失 —— `metadata`、`metadata-protocol`、`client`、`core/security` 里约 15 处
+  调用点今天就是这样(其中 `metadata/src/endpoint-matcher.ts` 送的正是一个 Zod issue 数组)。
+  契约的另外两个实现(`@objectstack/observability` 的 `ConsoleLogger`/`JsonLogger`)都老老实实
+  用了这个位置,所以是契约对、这一个实现错:declared ≠ enforced。
+
+  三种形状现在都被兑现,两个位置同时带值时以更靠后的 `meta` 为准。这一处修好之后,上述
+  调用点的诊断自动恢复(`client` 的 `HTTP request failed` 记录重新带上
+  `{method, url, status, error}`)。connector 接缝改用契约的第三参而非第二参,是刻意的:
+  把原始 error 塞进第二位会让每条记录都附带完整堆栈,ZodError 还会附带整段多行 dump ——
+  正是我们要消灭的无界形状。
+
+- eb3e650: fix(core): 健康检查的超时守卫在 race 落定时被清除,周期性检查不再堆积孤儿定时器 (#4875)
+
+  `PluginHealthMonitor.performHealthCheck()` 里那条 race 的守卫由 `timeout()` armed 之后就被
+  扔掉:插件的 `checkMethod` 赢下 race 之后,那根 `setTimeout` 既没 `clearTimeout` 也没
+  `unref()`,带着 ref 一直挂满整个 `config.timeout`。这与 #4813 修掉的两处(内核 init/start
+  守卫,PR #4874)是同一种漏法。
+
+  差别在于**健康检查是周期性的**:内核那两处是启动时一次性的固定份额(4 个插件 = 8 根),这里
+  则是**每个插件每一轮各留一根**,`interval` 越密、`timeout` 越长,堆得越高 —— 一个
+  `interval: 30s` / `timeout: 5s` 的插件在任意时刻都挂着若干根本该在毫秒级就回收的定时器。
+  今天这条还没发作,只是因为 `startMonitoring()` 目前没有被内核启动流程调用;一旦健康监控被接进
+  宿主,它就是 #4813 的放大版。
+
+  修法与 #4874 同形:`timeout()` 换成私有 helper `raceCheckTimeout()`,`try { await
+Promise.race(...) } finally { clearTimeout(guard) }`。
+
+  **为什么是 `clearTimeout` 而不是 `unref()`。** `unref()` 让定时器不再钉住事件循环的同时,
+  也让它不再是一个守卫 —— 若检查永不 settle 且没有别的东西撑着事件循环,Node 会在定时器触发
+  之前退出,超时被静默吞掉。守卫必须在 race 未决期间保持 ref'd、在落定那一刻被回收,这正是
+  `finally { clearTimeout(guard) }` 表达的语义。回归测试因此是三条:守卫赢不了时不留 ref'd
+  定时器、连跑多轮不累积(fake timers 下计数,能识破 `unref()` 式的假修复)、以及检查真的挂住时
+  超时照常上报。
+
+  超时时长(`config.timeout`)一个都没动 —— 问题从来不在时长,而在没人回收。
+
+- 674ac99: fix(core): one throwing `kernel:shutdown` handler no longer skips every plugin `destroy()` and kills the process under a false "Shutdown timed out" (#5274)
+
+  **On `ObjectKernel`, a single bad shutdown subscriber used to end the entire teardown
+  and `process.exit(1)` the host — reporting a timeout that never happened.**
+
+  `performShutdown()` dispatched `kernel:shutdown` through `context.trigger` (a bare
+  awaited loop that never catches), so the first handler that threw propagated out to
+  `shutdown()`'s `Promise.race` catch. That catch was written for the timeout race alone
+  and treated every exception as one, producing three consequences at once:
+
+  1. the remaining `kernel:shutdown` handlers never ran;
+  2. **every** plugin's `destroy()` was skipped — the reverse-order destroy pass sits
+     after the trigger in `performShutdown()`, so it was never reached;
+  3. the process was killed by `process.exit(1)` under the log line
+     `Shutdown timed out — forcing exit`, while nothing had timed out — sending whoever
+     read it to the `shutdownTimeout` config for a handler bug.
+
+  Two changes, matching the reasoning #5257 recorded at `LiteKernel`'s shutdown dispatch
+  site:
+
+  - **`kernel:shutdown` now dispatches ISOLATING on `ObjectKernel` too.** A handler that
+    throws is logged as `Hook handler failed: kernel:shutdown` and the remaining handlers
+    still run, followed by the reverse-order `destroy()` pass and the `onShutdown()`
+    handlers — both of which already isolated per plugin and per handler. What is queued
+    behind a failing shutdown handler is the cleanup that flushes buffers, closes
+    connections and releases locks, so one bad handler must not amplify into leaks and
+    unflushed writes. The BOOT-path hooks are untouched: `kernel:ready`,
+    `kernel:bootstrapped` and `kernel:listening` still propagate and still fail the boot
+    (#5170, #5257).
+  - **The timeout catch now handles only a genuine timeout**, discriminated by identity on
+    the timer's own rejection — not by message, not by type, so nothing a plugin throws
+    can impersonate it. A genuine `shutdownTimeout` overrun is **unchanged**: it still
+    logs `Shutdown timed out — forcing exit` and still calls `process.exit(1)`, because
+    teardown really is hung and the process would otherwise hold what it failed to
+    release. Any other exception is logged at `error` and follows the normal path —
+    `state = 'stopped'`, return — with no `process.exit`, leaving an embedding host
+    (cloud auth-proxy, CLI, a test runner) its own chance to finish cleanly.
+
+  `shutdown()` still never rejects, so no existing caller changes. Telling the two paths
+  apart is the point of the fix, and both are pinned by named tests.
+
+- 46365ab: fix(core): `ObjectLogger` 的脱敏表按**词边界**匹配,不再按子串吃掉 `keys`/`tokens` 这类普通字段 (#5573)
+
+  `redactSensitive` 此前的判定是 `key.toLowerCase().includes(pattern)` —— 只要字段名
+  **含有** `password`/`token`/`secret`/`key` 子串,整个值就被换成 `***REDACTED***`。
+  于是 `keys`、`keyword`、`keywords`、`keyboard`、`monkey`、`tokens`、`tokenizer`、
+  `secretary` 全部中招:读者不但丢了事实,还被告知"这里挡住了一个秘密",比字段直接
+  缺失更误导。仓库里已经有活的命中 —— `dispatcher-plugin.ts` 为了躲开脱敏器特意把
+  `key` 改名成 `keyedBy`,而 `'keyedby'.includes('key')` 依然为真,那条限流日志的
+  `keyedBy` 一直是 `***REDACTED***`。
+
+  匹配语义 FROM → TO:
+
+  |                                                        | FROM(子串 `includes`) | TO(词边界)           |
+  | :----------------------------------------------------- | :-------------------- | :------------------- |
+  | `apiKey` / `api_key` / `API_KEY` / `x-api-key`         | 脱敏                  | 脱敏(不变)           |
+  | `apikey` / `APIKEY`(全小写连写)                        | 脱敏                  | 脱敏(不变,见下)      |
+  | `apiKeys` / `refresh_tokens`(复合词里的复数)           | 脱敏                  | 脱敏(不变)           |
+  | `keys` / `tokens` / `keyword` / `monkey` / `secretary` | **脱敏**              | **不脱敏**           |
+  | `keyedBy` / `tokenizerName`                            | **脱敏**              | **不脱敏**           |
+  | `passwords` / `secrets`(裸复数)                        | **脱敏**              | **不脱敏**           |
+  | `api_key` 字段 + `redact: ['apiKey']` 配置             | **不脱敏**            | **脱敏**(跨拼法命中) |
+
+  字段名按 camelCase / snake_case / kebab-case / 字母-数字边界分词后逐词比对。默认脱敏表
+  (`['password','token','secret','key']`)本身**没有变**,`packages/spec` 的 schema 默认值
+  也没有变 —— 变的只是这张表怎么用。
+
+  两个边角是显式取舍,不是遗漏:
+
+  - **全小写连写**没有词边界可分,`apikey` 分词后只有一个词。不能用"以 `key` 结尾"救,
+    因为 `monkey`/`turkey`/`whiskey` 也以它结尾 —— 那正是本单要去掉的误报。所以连写只在
+    前缀是一张显式限定词表(`api`/`access`/`refresh`/`client`/`private`/`session`/…)里的
+    词时才算命中;表外的连写(`foobarkey`)不脱敏,按仓库命名惯例写成 `fooBarKey` /
+    `foo_bar_key` 即可通用命中。只认**后缀**连写,所以 `secretary`、`keyword` 保持干净。
+  - **裸复数**是集合或计数而不是秘密(`keys` 来自 Zod 的 `unrecognized_keys` issue,
+    `tokens` 来自 LLM 用量),按维护者裁决不脱敏;复数**出现在复合词里**时仍然是秘密
+    (`apiKeys: ['sk-…']`),照常脱敏。确实要脱敏裸复数的 host,写
+    `redact: [..., 'passwords']` 显式加回。
+
+  **影响面**:host 侧自定义 `redact` 配置的匹配行为随之收紧 —— 依赖子串宽匹配"顺手"挡住
+  某个字段的部署,需要把该字段名(或它的词)显式写进 `redact`。反向的收益是同一个词现在
+  跨拼法命中:配 `redact: ['apiKey']` 也会挡住 `api_key` 和 `apikey`。
+
+- c5adfe1: fix: 节点执行与热重载 shutdown 的超时守卫在 race 落定时被清除,不再留下孤儿定时器 (#4952)
+
+  #4813(PR #4874,内核 init/start)与 #4875(PR #4950,周期性健康检查)修掉的是同一种漏法:
+  守卫 armed 之后就被扔掉 —— 被守护的一方赢下 race 之后,那根 `setTimeout` 既没 `clearTimeout`
+  也没 `unref()`,带着 ref 一直把事件循环钉满整个超时预算。本次清仓剩下的两处生产实例:
+
+  - **`AutomationEngine.executeWithTimeout()`**(`service-automation`)—— 三处里量级最大的一处:
+    **每个声明了 `timeoutMs` 的流程节点各一根**,孤儿数随流程节点数 × 触发频率线性增长;一次性进程
+    (`os` CLI 跑到 flow 的路径)干完活之后还会被最长的那根守卫按住到超时才退出。
+  - **`HotReloadManager.reloadPlugin()`**(`core`)—— 插件 `destroy()` 的 shutdown 守卫,与 #4813
+    修掉的两处一字不差:一次毫秒级完成的热重载,照样把循环钉满 `shutdownTimeout`。
+
+  两处修法与 #4874 / #4950 同形,不新造变体:私有 helper +
+  `try { return await Promise.race([...]) } finally { clearTimeout(guard) }`。`hot-reload.ts` 的
+  helper 把入参放宽到 `T | PromiseLike<T>`(Plugin 契约允许同步 `destroy()`);`engine.ts` 的不放宽
+  (`NodeExecutor.execute` 声明返回 `Promise`)。
+
+  **为什么是 `clearTimeout` 而不是 `unref()`。** `unref()` 让定时器不再钉住事件循环的同时,也让它
+  不再是一个守卫 —— 若被守护的一方永不 settle 且没有别的东西撑着事件循环,Node 会在定时器触发之前
+  退出,超时被静默吞掉。守卫必须在 race 未决期间保持 ref'd、在落定那一刻被回收,这正是
+  `finally { clearTimeout(guard) }` 表达的语义。两处的回归测试各自沿用 #4950 的双向写法:
+  真实定时器下不留 ref'd 定时器、fake timers 下连跑多轮不累积(计数能看见 `unref()` 过的定时器,
+  因此识破 `unref()` 式的假修复)、以及被守护方真的挂住时超时照常上报。
+
+  超时时长(`timeoutMs` / `shutdownTimeout`)一个都没动 —— 问题从来不在时长,而在没人回收。
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [d9971d3]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Minor Changes
diff --git a/packages/core/package.json b/packages/core/package.json
index 3040ad5ed8..0af348ec0c 100644
--- a/packages/core/package.json
+++ b/packages/core/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/core",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "Microkernel Core for ObjectStack",
   "type": "module",
diff --git a/packages/create-objectstack/CHANGELOG.md b/packages/create-objectstack/CHANGELOG.md
index c804348a35..3c2001c7e2 100644
--- a/packages/create-objectstack/CHANGELOG.md
+++ b/packages/create-objectstack/CHANGELOG.md
@@ -1,5 +1,32 @@
 # create-objectstack
 
+## 17.0.0-rc.4
+
+### Patch Changes
+
+- 8d41998: fix(create-objectstack): scaffolding a remote template no longer produces a project that cannot build (#4926)
+
+  `npx create-objectstack@latest my-app -t todo` (and `compliance`, `content`,
+  `contracts`, `procurement`) generated a project that failed `objectstack build`
+  immediately — 5 of the 6 offered templates. Only the bundled `blank` worked.
+
+  The scaffolder read the template's original namespace from
+  `objectstack.manifest.json`, and that filename names two different documents.
+  The bundled template's is app-shaped and carries `namespace`; a remote
+  template's is the template-registry document
+  (`$schema: …/template-manifest.json`) and carries none — its namespace lives
+  only in `objectstack.config.ts`. So the value came back `undefined` for every
+  remote template and the object-name rewrite was skipped, while the config's
+  `namespace:` was rewritten anyway. The result was `namespace: 'my_app'` sitting
+  next to `name: 'todo_task'`, which the `${namespace}_${shortName}` rule rejects.
+  Across the five templates, 74 object names were left unrewritten.
+
+  `objectstack.config.ts` is now the authority for the template namespace (it
+  holds the very literal the scaffolder overwrites, so the two cannot disagree),
+  with the manifest as fallback. The rewrite also verifies itself: any surviving
+  stale prefix throws at the scaffold, naming the files and lines, instead of
+  surfacing as a build failure on the user's first command.
+
 ## 17.0.0-rc.2
 
 ## 17.0.0-rc.1
diff --git a/packages/create-objectstack/package.json b/packages/create-objectstack/package.json
index 96b963f1ff..209b1f1ad8 100644
--- a/packages/create-objectstack/package.json
+++ b/packages/create-objectstack/package.json
@@ -1,6 +1,6 @@
 {
   "name": "create-objectstack",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "description": "Create a new ObjectStack project — npx create-objectstack",
   "bin": {
     "create-objectstack": "./bin/create-objectstack.js"
diff --git a/packages/drivers/driver-memory/CHANGELOG.md b/packages/drivers/driver-memory/CHANGELOG.md
index 33eb02d1a0..4697d7349e 100644
--- a/packages/drivers/driver-memory/CHANGELOG.md
+++ b/packages/drivers/driver-memory/CHANGELOG.md
@@ -1,5 +1,627 @@
 # @objectstack/driver-memory
 
+## 17.0.0-rc.4
+
+### Minor Changes
+
+- f7df82c: fix(driver-memory): the analytics (cube) face stops round-tripping filter comparands through `string[]`, which was losing booleans, `null` and numeric-looking strings (#5373)
+
+  **This is an observable behaviour change on a shipped surface: widgets whose
+  `where` carries a boolean, a `null`, or a numeric-looking string comparand will
+  show different — correct — numbers.** Some of them go from zero rows to a real
+  answer; others go from the whole table down to the rows actually asked for.
+
+  ## What was happening
+
+  `MemoryAnalyticsService` lowers `AnalyticsQuery.where` into a cube-style
+  `{member, operator, values}` list whose `values` was typed `string[]`, because
+  the cube WIRE format serialises filter values as strings. So every comparand
+  made a JS value → string → JS value round trip on its way to the pipeline, and
+  that round trip is lossy for anything that is not already a string:
+
+  | `where`                       | stringified | recovered as         | compared against      | rows                |
+  | ----------------------------- | ----------- | -------------------- | --------------------- | ------------------- |
+  | `{is_active: true}`           | `'1'`       | the number `1`       | stored `true`         | **0**               |
+  | `{is_active: false}`          | `'0'`       | the number `0`       | stored `false`        | **0**               |
+  | `{closed_at: null}`           | —           | _(dropped entirely)_ | —                     | **the whole table** |
+  | `{closed_at: {$ne: null}}`    | `''`        | `''`                 | stored `null`         | **the whole table** |
+  | `{code: '100'}` (TEXT column) | `'100'`     | the number `100`     | stored `'100'`        | **0**               |
+  | `{is_active: {$ne: true}}`    | `'1'`       | the number `1`       | stored `true`/`false` | **the whole table** |
+
+  mingo compares across JS types the way MongoDB compares across BSON types —
+  never equal — so none of these is an error. Each is a wrong row set, silently.
+
+  The two directions fail differently, and the widening one is worse. A boolean
+  filter that returns nothing renders an empty chart, which someone notices. A
+  `null` filter that returns everything renders a _normal-looking_ chart: a
+  "closed_at is empty" widget quietly counted the closed records too. That is the
+  direction #3948 outlawed, and on an RLS read scope it is an unauthorized read
+  rather than a wrong number.
+
+  `{is_active: true, stage: {$nin: ['lost']}}` is `AnalyticsQuerySchema.where`'s
+  own docstring example. It returned zero rows on this face.
+
+  ## Why the encoding could not simply be fixed
+
+  `stringifyForCube` encoded booleans as `'1'`/`'0'` "so that downstream consumers
+  expecting SQLite-style numeric booleans match correctly". That justification is
+  sound for the SQL-generating exit and false for the in-memory one — and both
+  exits shared the single encoding. There is no string spelling of `true` that is
+  right for `WHERE is_active = ?` and for a mingo `$eq` against a stored boolean at
+  the same time, so making the round trip lossless would have meant tagging values
+  in a format the two exits then have to agree to decode.
+
+  So the round trip is **gone** instead. `values` is `unknown[]`; the comparand
+  stays whatever the author wrote, and each exit converts at its own boundary
+  where it knows what it needs. This is affordable because the triple is a purely
+  internal intermediate: `AnalyticsQuery.where` is a `FilterCondition` and nothing
+  else (#5375 removed the leg that also accepted a cube-style array as input), and
+  the API layer actively rejects a `{member, operator, values}` array on the wire.
+  No caller, no spec schema and no serialized form observes its shape — this
+  change touches zero spec bytes.
+
+  ## What changes for you
+
+  Filters are evaluated against the values you wrote:
+
+  - `{is_active: true}` selects the true rows instead of none.
+  - `{closed_at: null}` selects the null rows instead of every row, and
+    `{closed_at: {$ne: null}}` selects the complement instead of every row.
+  - `{code: '100'}` on a TEXT column matches the string `'100'` instead of nothing.
+  - `{qty: 100}` on a numeric column is unchanged — it was already right.
+
+  `generateSql()` is corrected on the same cases, because a fix that satisfied
+  mingo while emitting SQL meaning something else would only have moved the bug:
+
+  - a numeric-looking string is now quoted (`code = '100'`, previously `code = 100`)
+    while a real number still is not (`qty = 100`);
+  - a null comparand becomes a nullness test (`closed_at IS NULL` /
+    `closed_at IS NOT NULL`) rather than the `= NULL` that is never true in SQL,
+    or — as before this fix — no clause at all;
+  - booleans keep the SQLite-style `1`/`0` spelling, which was always right for
+    this half.
+
+  Temporal comparands still convert, and now do so through the driver's own
+  storage-form rule (`filterComparandStorageForm`, keyed on the declared field
+  kind, #4047) rather than an ad-hoc `toISOString()`. A `Date` against a declared
+  `datetime` column therefore keeps meeting the canonical UTC ISO text the driver
+  wrote — a second derivation of that rule inside the analytics face is exactly
+  the in-package divergence #5240 ruled against.
+
+  Nothing else moves: operator vocabulary, the #5345 refusals, `$and` folding,
+  nested-relation flattening, time dimensions and the empty filter are unchanged.
+
+  ## Coverage
+
+  The cases live in the shared conformance file beside the #5324/#5345 shape
+  table, not in a suite of their own. `FILTER_LOGIC_CASES` varies the filter's
+  SHAPE over an all-string fixture — deliberately, so nothing in it is about
+  coercion — which is why every one of its cases stayed green through this defect.
+  The new block varies the comparand's TYPE over the fixture measured in the
+  issue, and holds the same invariant: the analytics face must return the same ids
+  as `find()`, or refuse. Reverting only the source change fails 11 of the new
+  assertions, across both exits.
+
+- d085670: fix(driver-memory): the analytics (cube) face REFUSES a filter it cannot compile instead of silently dropping it (#5345)
+
+  **This is an observable behaviour change on a shipped surface, and it will turn
+  some working-looking dashboards red.** That is the point: the widgets it breaks
+  were returning inflated aggregates, and some of them were returning rows the
+  caller had no permission to read.
+
+  ## What was happening
+
+  `MemoryAnalyticsService` lowers `AnalyticsQuery.where` into a flat, cube-style
+  `{member, operator, values}` list. Anything that did not fit was answered with
+  `continue` — in two places, and with a comment presenting it as a feature
+  ("ignore so a partial query still runs rather than failing entirely"):
+
+  | dropped                     | why it did not fit                                   |
+  | --------------------------- | ---------------------------------------------------- |
+  | `$or` (whole branch)        | no expression in a flat AND-list                     |
+  | `$not` (whole branch)       | same                                                 |
+  | `$between`                  | no row in the mongo→cube operator table              |
+  | `$startsWith` / `$endsWith` | same                                                 |
+  | `$null`                     | same                                                 |
+  | `$regex`                    | same — and `plugin-auth`'s ObjectQL adapter emits it |
+
+  Dropping a predicate does not narrow a query, it **widens** it: fewer
+  constraints means more rows. A widget filtered to two stages with
+  `{$or: [{stage: 'won'}, {stage: 'lost'}]}` aggregated the **entire table** and
+  rendered as a perfectly normal chart. Measured on the shared
+  `FILTER_LOGIC_CASES` fixture, **15 of its 17 cases** returned a wider row set
+  than the standard specifies — usually every row. Of the two that did agree, one
+  (`a $or nested under a top-level $and`) agreed by _coincidence_: its dropped
+  `$or` happened to be redundant against a surviving sibling key, which is the
+  best illustration available of why "the number looked right" was never evidence.
+
+  `$not` makes it more than a wrong number. `cel-to-filter.ts` compiles a CEL
+  `!expr` RLS read scope into `{$not: {…}}`, so the dropped branch was the read
+  scope itself — the aggregate included records the caller is not allowed to see.
+
+  ## What changes for you
+
+  A `where` carrying any of the shapes above now raises **`INVALID_FILTER` / 400**
+  (the ADR-0112 envelope every sibling filter refusal in this driver already
+  speaks, reaching REST callers as a 400 since #5366) naming the offending
+  operator or combinator and its position, e.g.:
+
+  > Filter operator `"$between"` on field `"amount"` at `where.amount` is declared
+  > by the Filter Protocol but cannot be compiled by driver-memory's analytics
+  > (cube) face. Supported operators on this surface: `$eq, $ne, $gt, $gte, $lt,
+$lte, $in, $nin, $contains, $notContains, $exists`.
+
+  Both entry points refuse identically — `query()` and `generateSql()`.
+
+  **The fix, per shape:**
+
+  - `$between` on a range → the two bounds, which this face has always compiled:
+    `{ closed_at: { $gte: '2026-01-01', $lte: '2026-01-31' } }`, or a
+    `timeDimensions[].dateRange`, which is unaffected.
+  - `$startsWith` / `$endsWith` / `$regex` → `$contains`, or move the query to
+    `find()`.
+  - `$null` → `{ field: { $exists: false } }` for the absent case.
+  - `$or` / `$not` → restate as the implicit AND of field keys where the intent
+    allows it; where it does not, the cube pipeline genuinely cannot express it,
+    and the query belongs on `find()`.
+
+  Nothing that was **compiled** changes. All eleven supported operators, `$and`,
+  implicit equality, nested-relation flattening, time dimensions and the empty
+  filter produce byte-identical pipelines.
+
+  ## Why refuse rather than teach the cube pipeline `$or`
+
+  This is the call ADR-0078 / #4286 made for `objectql`'s `having` — an ignored
+  operator there "silently returns UNFILTERED aggregates", so it throws — and the
+  posture #3948 established for every filter backend: a filter that cannot be
+  compiled is refused loudly, never skipped. It is also where the two neighbouring
+  faces landed (#5366, #5368).
+
+  Mechanically, the refusal is not a new check bolted onto this face. It reuses
+  the package's single filter gate, `assertFilterConditionShape`, which now takes
+  the calling face's declared capabilities; and the analytics face derives those
+  capabilities from its own mongo→cube operator table, so widening what it accepts
+  and teaching it to compile the operator are now the same edit. The shared
+  `FILTER_LOGIC_CASES` conformance table covers this third face for the first time
+  (it watched only two of the driver's three), holding it to: agree with
+  `find()`, or refuse — never a third, quieter answer.
+
+- 01c0bae: fix(driver-memory): the analytics (cube) face compiles `$notContains` to a predicate that actually excludes rows, instead of a bare mingo `{$not: 'x'}` that constrains nothing (#5374)
+
+  **This is an observable behaviour change on a shipped surface: widgets whose
+  `where` carries `$notContains`, `$contains`, or an empty `$in` will show
+  different — correct — numbers.** Every one of them moves in the same direction,
+  from a wider row set to the rows actually asked for, because each of these
+  defects made a predicate mean less than it says.
+
+  ## What was happening
+
+  `MemoryAnalyticsService` mapped each cube operator to the NAME of a mingo
+  operator, and the call site filled that name in as
+  `matchStage[field] = {[name]: comparand}`. That shape can express "compare this
+  field to this value" and nothing else, so the two operators that need to WRAP
+  their comparand were pushed through it anyway:
+
+  | `where`                        | compiled `$match`           | analytics | `find()` |
+  | ------------------------------ | --------------------------- | --------- | -------- |
+  | `{name: {$notContains: 'et'}}` | `{name: {$not: 'et'}}`      | **3**     | 2        |
+  | `{name: {$notContains: 'a'}}`  | `{name: {$not: 'a'}}`       | **3**     | 0        |
+  | `{name: {$contains: 'a.p'}}`   | `{name: {$regex: 'a.p'}}`   | **1**     | 0        |
+  | `{name: {$contains: 'ALPHA'}}` | `{name: {$regex: 'ALPHA'}}` | **0**     | 1        |
+  | `{code: {$in: []}}`            | _(no predicate emitted)_    | **3**     | 0        |
+
+  - **`notContains` → `'$not'`.** mingo's `$not` takes a regex or an operator
+    expression; handed a bare scalar it constrains nothing. The predicate was
+    emitted, appeared in the pipeline, and passed the whole table. A predicate
+    that is emitted and inert is indistinguishable from a working one at the
+    author's end — the same amplifying direction as #3948, reached a third way.
+  - **`contains` → `'$regex'`** was the right operator with the comparand handed
+    in raw, so it was neither escaped (a `.` matched any character) nor
+    case-folded, while the live query path escapes and matches `/…/i`. One
+    `where`, two meanings, depending on which face read it (#5240).
+  - **an empty `$in`** hit the call site's `values.length > 0` guard and emitted
+    no predicate at all, so the query widened to the whole table where `find()`
+    returned nothing.
+  - **an operand that is not a comparand** — a `$contains` pattern, a `$exists`
+    flag — went through the field's storage-form conversion anyway, so on a
+    declared `datetime` column the PATTERN itself was rewritten into canonical
+    form and then matched rows `find()` does not match (#4047).
+
+  ## What changed
+
+  The operator table now holds a **predicate builder** per operator rather than an
+  operator name, so `notContains` can say `{$not: {$regex: …}}` and the class of
+  "this operator needs a structure and the table can only hold a name" is gone
+  rather than this one instance of it. `$in` / `$nin` / `$lte` / `$exists`, which
+  the call site had grown an `if` chain for, are ordinary rows in that table now.
+
+  The substring rule itself is **borrowed from the driver** (new narrow
+  `InMemoryDriver.filterSubstringPattern`, alongside `filterComparandStorageForm`)
+  instead of re-derived, so `contains` on the analytics face escapes and case-folds
+  exactly as `find()` does and the two cannot drift apart again.
+
+  The `opMap[operator] || '$eq'` fallback — under which a misspelled or unmapped
+  operator silently became an EQUALITY comparison — is gone. It was already
+  unreachable after #5345 gated the vocabulary upstream, but only until someone
+  widened that vocabulary, which #5345 deliberately made a one-line edit. The
+  predicate table is keyed by the operator union derived from that same table, so
+  the widening edit now **fails to compile** until the predicate exists.
+
+  Two dead entries were deleted with it: `'notSet': '$exists'` (unreachable, and
+  inverted if it ever had been reached) and `'inDateRange': '$gte'` (unreachable,
+  and a one-ended `>=` answer to a two-ended range — its own comment conceded
+  "Will need special handling" and nothing implemented it).
+
+  ## Not changed
+
+  The `generateSql()` exit is untouched. Its operator-layer defects are #5433,
+  filed and deliberately not bundled.
+
+- 0f17114: fix(driver-sql,driver-memory,formula)!: `{ field: {} }` 一律拒收 —— 零个操作符的字段约束不再在四个后端有三个答案 (#5240)
+
+  `{ a: {} }`(一个字段,后面跟零个操作符)是 `FilterConditionSchema` 今天**声明合法**的形状,
+  而同一个 filter 在同仓四条路径上有三个答案:
+
+  | 路径                                | 改前                                                                                            | 改后                          |
+  | ----------------------------------- | ----------------------------------------------------------------------------------------------- | ----------------------------- |
+  | `driver-sql`,顶层 plain map         | 抛 `INVALID_FILTER`(#5041 的比较数闸门)                                                         | 抛 `INVALID_FILTER`(专用消息) |
+  | `driver-sql`,`$and`/`$or`/`$not` 内 | 遍历零个操作符 → 不产出任何 SQL → **TRUE(匹配全表)**                                            | 抛 `INVALID_FILTER`           |
+  | `driver-memory`                     | 实时路径经 mingo 变成「字段深等于空文档」;参考匹配器落到 `JSON.stringify` 结构相等 → 顺带 FALSE | 抛 `INVALID_FILTER`           |
+  | `@objectstack/formula`              | `keys.length === 0` 显式 fail-closed → FALSE                                                    | 抛 `INVALID_FILTER`           |
+
+  于是 `{ $or: [ { a: {} }, { b: 2 } ] }` 在 SQL 上编译成 `(b = 2)` —— 既不是「零约束即 TRUE」
+  该给的全表,也不是两个 JS 后端给的 FALSE,而是**子句被 knex 连同空分组一起丢掉**的结果;
+  而 `driver-sql` 自己内部就不自洽:同一个 `{ a: {} }` 写在顶层被响亮拒收,包进一层 `$or`
+  就变成静默的 TRUE。
+
+  维护者拍板取**拒收**(不取 TRUE、不取 FALSE):这个形状几乎必然是编写期事故 ——
+  筛选器记下了字段却没记下操作符,或生成的元数据把操作符弄丢了 —— 让它在编写期就炸,
+  好过在某个后端上安静地多返回或少返回几行。与 #5041 已在 driver-sql 顶层建立的先例一致,
+  本次只是把同一道闸门补进组合子内部。四个后端(第四个是继承 `SqlDriver` 的
+  `driver-sqlite-wasm`)现在给出同一个 `INVALID_FILTER` / 400,消息里指名出事的位置
+  (如 `filter.$or[0].stage`)。
+
+  **⚠️ 可观察的行为变更 —— RLS `check` 求值路径。** `@objectstack/formula` 的
+  `matchesFilterCondition` 是 `plugin-security` 对 insert/update **后像**执行行级 `check`
+  的那条路径(没有查询可下推,这个求值器就是执行本身)。它改为抛出后,落在 #4775
+  「求不出值 = 该次操作失败」的既定姿态上。这不只是「拒绝得更响」——有一类结果直接翻转:
+
+  | `check` 策略                                    | 改前                                  | 改后                     |
+  | ----------------------------------------------- | ------------------------------------- | ------------------------ |
+  | `{ a: {} }`                                     | FALSE → 写入被拒(403)                 | 抛出 → 该次写入失败(400) |
+  | `{ $or: [ { a: {} }, { owner: '{userId}' } ] }` | FALSE 被另一析取项吸收 → 写入**放行** | 抛出 → 该次写入失败      |
+  | `{ $not: { a: {} } }`                           | `!false` → 写入**放行**               | 抛出 → 该次写入失败      |
+
+  后两行是**原本能成功、现在会失败**的写入。这是拍板的目的而非副作用:一条含
+  `{ field: {} }` 的权限规则,是一条作者弄丢了操作符的规则,它的含义不该取决于四个后端里
+  哪一个在求值。升级后请检查 `check`/`using` 策略里是否存在零操作符的字段约束——
+  错误消息会指名位置。
+
+  同一条改动也让 `@objectstack/driver-memory` 的两个过滤面(经 mingo 的实时查询路径,
+  与跨后端一致性套件所用的 `memory-matcher` 参考匹配器)第一次对这个形状给出同一个答案。
+
+  非空形状**逐字符不变**:普通比较、`$in`、`$or`/`$and` 组合、`$not` 的 #5146 NULL-safe 改写,
+  编译出的 SQL 文本与匹配结果都与改前相同;`{}`(零个键的**节点**,#5134 的布尔单位元)
+  与 `{ field: {} }` 是两个不同形状,前者的语义不受本次影响。
+
+  注:本次收紧的是**实现**。`packages/spec` 的 `FilterConditionSchema` 仍然声明这个形状合法
+  (非递归半边是 `z.record(z.string(), z.unknown())`),即实现现在比已声明的契约更严;
+  契约收窄与 `FILTER_LOGIC_CASES` 补条归 spec 车道另行处理。
+
+- c7406b0: fix(objectql,driver-sql,driver-memory,driver-mongodb)!: `FilterArray` 在 engine 门下沉,四驱动的数组方言删除 (#5158 拍板 C 第 2 步)
+
+  `FilterArray` —— `['stage','=','won']`、`['and', […], […]]`、`[[…], […]]` —— 是**仅输入**的
+  授权糖。#5285 已在 spec 里把这件事写明(`data/filter.zod.ts`,`filter-array-declaration.test.ts`
+  钉住「被声明」且「`where` 不接受它」)。本次是拍板 C 的第 2 步:让**运行时**与那份声明一致。
+
+  ## 改了什么
+
+  进入运行时的门有两扇,过去只有一扇按契约读:
+
+  | 门                                                                                                | 改前                                                                                                                               | 改后                                                                                            |
+  | ------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
+  | **Door 1** —— 协议/HTTP 面(`metadata-protocol`)                                                   | `isFilterAST` → `parseFilterAST`,不可下沉的数组答 `400 INVALID_FILTER`                                                             | 不变                                                                                            |
+  | **Door 2** —— 进程内 engine 直调(`ObjectQL.find`/`findOne`/`count`/`aggregate`/`update`/`delete`) | 数组**原样**透传给驱动                                                                                                             | 走**同一条缝**:`isFilterAST` → `parseFilterAST` 下沉为 `FilterCondition`,不可下沉的数组响亮拒收 |
+  | 四驱动(`driver-sql`、继承它的 `driver-sqlite-wasm`、`driver-memory`、`driver-mongodb`)            | 各自带**第二套过滤器编译器**,包括一种**中缀**方言(`[condA, 'or', condB]`)—— 没有任何 schema 声明过它,`parseFilterAST` 也表达不了它 | 数组方言删除;数组到达驱动即 `INVALID_FILTER` / 400                                              |
+
+  一个查询两套编译器正是 ADR-0053 D-A1 禁止的分叉,而且它已经产生了真实的产品分叉:cloud 的
+  `RemoteTransport.buildWhereSQL` 自 cloud#1075 起对**同一输入**响亮拒收,`driver-sql` 却编译它。
+  删掉方言后两侧自然合流。
+
+  ## 授权面:零变化
+
+  `FilterBuilder`(`@objectstack/client`)产出的元组与 `['and', ...]` 组、React block 的
+  `filters` prop、wire 的 `$filter` 面、showcase 的授权点 —— **全部原样工作**,因为下沉正是
+  这些形状本来的用途。wire 契约逐字节不变(Door 1 的行为未改)。
+
+  ## ⚠️ 可观察的行为变更
+
+  1. **中缀连接不再被编译。** `where: [condA, 'or', condB]` 过去只有驱动认识,现在在 engine 门被拒收。
+     声明的写法是前缀组:`['or', condA, condB]` —— 语义相同,`parseFilterAST` 有它的下沉。
+  2. **`findOne({ where: [] })` 现在抛错。** `[]` 的含义**没有变**(仍是「无过滤」,`find`/`count`
+     照旧返回/计数全部行)。变的是 `findOne` 终于**看得见**这一点:未下沉的 `[]` 过去被
+     `requireFindOnePredicate` 当作「驱动自己去解释的表达式树」放行,于是 `limit: 1` 落在整张表上,
+     返回**任意一行** —— 正是 #4419 要挡的缺陷,活在 #4419 自己的守卫里面。
+  3. **不可下沉的数组在 engine 门拒收,不再由驱动拒收。** 形状与操作符词表相同(`isFilterAST` 同一套),
+     变的是消息来自调用点、带上调用方自己的值,以及明说「过滤器没有被应用,否则会返回**未过滤**的结果集」。
+  4. **驱动直调者(不经 engine)受影响。** `SqlDriver` / `InMemoryDriver` / `translateFilter` 是公开
+     导出;把数组 `where` 直接喂给它们的调用方需要改为先 `parseFilterAST(...)` 再传,或改走 ObjectQL。
+     注意 `QueryAST.where` 的 `FilterCondition` 是索引签名类型,数组对它是**可赋值**的 —— 类型层从未
+     挡住这个输入,所以拒收必须在运行时。
+  5. **`driver-mongodb` 的 `createdAt` → `created_at` 字段别名随方言一起消失。** 它只存在于数组路径
+     (`mapFieldName`,仅被已删除的 `translateComparison` 调用),对象路径从未应用过它。消费端别名按
+     AGENTS.md PD #12 是债务而非模式,故不再补回:请写声明的字段名 `created_at`。
+
+  ## 删除的代码面
+
+  - `SqlDriver.applyFilters` 的数组遍历分支,及其比较发射器 `protected applyAstComparison`(约 220 行)
+  - `InMemoryDriver.convertToMongoQuery` 的 legacy array 分支(约 62 行)
+  - `driver-mongodb` `mongodb-filter.ts` 的 `translateArrayFilter` / `translateComparison` / `mapFieldName`(约 140 行)
+  - `driver-sqlite-wasm` 无自有实现,随 `SqlDriver` 继承变更
+
+  `[]` 在每一层的读法**都不变**:engine 删键、`parseFilterAST([])` 为 `undefined`、三个驱动都提前返回。
+
+### Patch Changes
+
+- 06ba036: feat(drivers): `@objectstack/driver-turso` 迁回本仓并公开发布，五个 driver 统一收进 `packages/drivers/` (#4645)
+
+  `TursoDriver` 一直以 `extends SqlDriver` 的方式**跨仓库继承**本仓的类，自己却住在闭源的
+  `objectstack-ai/cloud`（`publishConfig: restricted`）。而本仓的 runtime 早就把 turso 当一等
+  公民——`http-dispatcher.ts` 里环境 provisioning 的偏好顺序第一位就是它，`POST /cloud/environments`
+  的 `driver` 参数示例是 `memory | turso`，`objectql/src/engine.ts` 还带着一段 turso 专属的瞬时
+  `fetch failed` 重试。开源侧的代码路径引用着一个自己仓里既测不到也 grep 不到的 driver，闭源侧则
+  在每次 pin bump 时追赶父类的重构。维护者裁定把核心迁回本仓、公开 Apache-2.0 发布。
+
+  **新包 `@objectstack/driver-turso`（`packages/drivers/driver-turso`，Apache-2.0，`access: public`）**
+  带着它在 cloud 的全部实现与测试落地：`TursoDriver`（local / replica / remote 三种传输模式）、
+  `RemoteTransport`（纯 `@libsql/client` 走 HTTP/WebSocket，无原生依赖，可跑 serverless/edge）、
+  驱动的 spec/Studio 元数据，以及 15 个测试文件 538 条断言——全部 hermetic，默认 CI 下不碰网络、
+  不要凭据（remote 面走包内的 sqlite stub）。
+
+  **留在 cloud（不随迁）**：按租户路由的 `multi-tenant.ts`（云产品差异化能力）及其 schema、
+  `vector-poc.test.ts`。因此本包的 barrel **不再导出** `createMultiTenantRouter` /
+  `MultiTenantConfig` / `MultiTenantRouter`，也不导出多租户 schema——它们从来不是这个 driver 的
+  一部分，只是曾经同包而已。
+
+  **目录重组**：五个 `IDataDriver` 实现（`driver-memory` / `driver-mongodb` / `driver-sql` /
+  `driver-sqlite-wasm` + 迁入的 `driver-turso`）现在都住在 `packages/drivers/`，
+  `knowledge-*` 与 `embedder-*` 留在 `packages/plugins/`。四个存量包**内容零改动**，只有
+  `repository.directory` 随目录更新——包名、入口、导出面、行为全部不变，消费者无需改动任何 import。
+
+  这也把 turso 交给了本仓的仓库级守卫：`check:driver-conformance` 从磁盘发现 driver 包，
+  迁入即入矩阵（5 drivers × 5 case-sets）。它的 temporal 两格是真绿（local 与 remote 双面套件），
+  filter 组合语义与两个分页 case-set 记为 measured DEBT——remote 传输自带一套 `buildWhereSQL` 与
+  `LIMIT`/`OFFSET` 拼装，是独立实现，"继承所以没问题"正是这些共享套件存在来证伪的假设。
+  补齐工作跟踪在 #5590。
+
+- 60a7a2d: fix(driver-memory): the live query path refuses the filters it cannot evaluate, and compiles the one it must (#5324, #5328)
+
+  **This is an observable behaviour change.** Two filter shapes that used to be
+  answered _silently_ now raise the catalogued `INVALID_FILTER` / 400 every other
+  filter refusal in this driver and in `driver-sql` already speaks (ADR-0112):
+
+  | filter                                                                                                                              | before                                                                                                                       | now                                                                     |
+  | ----------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------- |
+  | an operator outside the Filter Protocol — `{ name: { $sounds_like: 'x' } }`, `$elemMatch`, `$size`, `$where`, field-level `$not`, … | handed to mingo, which threw a `MingoError` carrying **no `code` and no `status`** — served as a 500-shaped `{ error }` body | `INVALID_FILTER` / 400, naming the operator, the field and its position |
+  | a `$between` whose comparand is not `[min, max]` — `{ score: { $between: 5 } }`                                                     | the arm was skipped, the constraint **vanished**, and `find` returned `[]`                                                   | `INVALID_FILTER` / 400, wording aligned with `driver-sql`'s             |
+
+  Two more shapes join them, same cause: an undeclared `$`-combinator in a node
+  position (`{ $nor: … }`, `{ $where: … }` — `FilterConditionSchema` declares
+  `$and`/`$or`/`$not` and nothing else), and a combinator operand that is not a
+  filter condition (`{ $or: 'x' }`, `{ $or: [null] }`, `{ $not: 'x' }`).
+
+  If a query of yours starts returning a 400, it was already broken — it was
+  returning an empty result set or an uncoded 500 for the same input, and
+  `driver-sql` was rejecting it. The message names the operator and the path
+  (`filter.$or[1].$and[0].stage`).
+
+  **`$not` is the opposite change: it now works.** `$not` is a declared combinator
+  (`LOGICAL_OPERATORS`), `cel-to-filter` emits it for every CEL `!expr` in an RLS
+  read scope, and `driver-sql` / `driver-mongodb` / this package's own reference
+  matcher all implement it — but the live query path passed it to mingo, and
+  MongoDB has no document-level `$not`, so **every query carrying a negated scope
+  threw** `unknown top level operator: $not`. It is compiled to `$nor` with one
+  operand, the same rewrite `driver-mongodb` performs, which is NULL-safe by
+  construction and therefore lands on the answer #5146 ruled canonical.
+
+  Both of this package's filter faces — the live mingo path and the reference
+  matcher — now share ONE shape gate, so they cannot answer one filter
+  differently again. They did: given a malformed `$between` the live path returned
+  NO rows while the matcher returned EVERY row.
+
+  The conformance gap that hid all of this is closed too. `FILTER_LOGIC_CASES`
+  was run against this backend through the reference matcher only — the driver
+  does not call it — so the table's `$not` case had been green for as long as it
+  existed while the same filter through `InMemoryDriver.find` threw. The table now
+  runs through the real driver, as it does for the other three backends.
+
+  Accepted operators are the spec's `FILTER_OPERATORS`, plus `$regex` (produced by
+  plugin-auth's ObjectQL adapter, compiled by `driver-sql`) and its `$options`
+  companion. `$options` is a modifier, not a predicate: on its own, with no
+  `$regex` beside it, it is refused like any other filter this driver cannot
+  evaluate — it used to raise the same uncoded engine error on the live path and
+  match every row in the matcher.
+
+- 9c5abf4: fix(driver-sql,driver-memory,driver-mongodb): refuse out-of-contract filter input at the door instead of answering it differently per backend (#5347, #5348)
+
+  Two shapes the Filter Protocol never declared were reaching the drivers, and
+  every driver ANSWERED them — with a different answer. Both are now refused with
+  `INVALID_FILTER` / 400, in the ADR-0112 envelope every sibling filter refusal
+  already speaks.
+
+  ## `$null` with a non-boolean comparand — a behaviour change you can observe
+
+  `FieldOperatorsSchema` declares `$null: z.boolean()`. A non-boolean was read by
+  default branches hung on opposite sides, so one filter meant opposite things per
+  backend. Measured against one row with `stage: 'won'` (id 1) and one with
+  `stage: null` (id 2), on `{ stage: { $null: 'yes' } }`:
+
+  | backend                                     | read as                           | rows        |
+  | ------------------------------------------- | --------------------------------- | ----------- |
+  | driver-sql, driver-sqlite-wasm, Turso local | IS NULL (anything but `false`)    | `["2"]`     |
+  | driver-memory query path, driver-mongodb    | IS NOT NULL (anything but `true`) | `["1"]`     |
+  | driver-memory reference matcher             | no constraint at all              | `["1","2"]` |
+
+  **What changes for you:** a caller that today gets rows back for
+  `{ field: { $null: <non-boolean> } }` now gets a `400 INVALID_FILTER` naming the
+  operator, the field and the position. That includes calls working by truthy /
+  falsy coincidence — and the sharpest case is the STRING `"false"`, which is
+  truthy: it compiled to IS NULL on SQL and IS NOT NULL on the JS backends, i.e.
+  the opposite of what its author wrote it to mean, on at least one of them
+  whichever they meant. A JSON round-trip or generated metadata produces it
+  readily.
+
+  **The fix:** write the boolean. `{ field: { $null: true } }` for "has no value",
+  `{ field: { $null: false } }` for "has a value". Both are unchanged, on all four
+  backends, and so is every other operator. `$exists` is deliberately NOT tightened
+  here — it diverges on its own axis (what "exists" means for a null-valued key)
+  and is tracked separately.
+
+  ## An undeclared `$op` in a document position — silent empty set becomes a 400
+
+  `FilterConditionSchema` declares exactly three `$`-keys at a node
+  (`$and` / `$or` / `$not`); every other key is a field name. `driver-sql`
+  compiled the rest as COLUMNS, so `{ $where: '…' }`, `{ $nor: […] }`,
+  `{ $expr: … }` produced a predicate that matched nothing and reported nothing —
+  a caller could not tell "no rows matched" from "the filter never compiled". The
+  FIELD position had refused the same class of input since v16, so one driver gave
+  two answers depending on depth.
+
+  **What changes for you:** those filters now raise `400 INVALID_FILTER` instead of
+  returning `[]`. `driver-memory` already refused them; this brings `driver-sql`
+  (and `driver-sqlite-wasm`, which inherits it) into line. The three declared
+  combinators, their boolean identities (`$and: []` is TRUE, `$or: []` is FALSE)
+  and every legal filter compile byte-identically.
+
+  Both refusals are raised on the driver's validating walk rather than in its SQL
+  emitter, so a malformed node is refused regardless of whether a sibling
+  disjunct would have short-circuited the compile.
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [b746aa0]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [d9971d3]
+- Updated dependencies [eb3e650]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [46365ab]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [c5adfe1]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/core@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Major Changes
diff --git a/packages/drivers/driver-memory/package.json b/packages/drivers/driver-memory/package.json
index 0fe73f20be..1b5387aa6f 100644
--- a/packages/drivers/driver-memory/package.json
+++ b/packages/drivers/driver-memory/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/driver-memory",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "In-Memory Driver for ObjectStack (Reference Implementation)",
   "main": "dist/index.js",
diff --git a/packages/drivers/driver-mongodb/CHANGELOG.md b/packages/drivers/driver-mongodb/CHANGELOG.md
index f2504ac4a4..d8465b97ca 100644
--- a/packages/drivers/driver-mongodb/CHANGELOG.md
+++ b/packages/drivers/driver-mongodb/CHANGELOG.md
@@ -1,5 +1,310 @@
 # @objectstack/driver-mongodb
 
+## 17.0.0-rc.4
+
+### Minor Changes
+
+- c7406b0: fix(objectql,driver-sql,driver-memory,driver-mongodb)!: `FilterArray` 在 engine 门下沉,四驱动的数组方言删除 (#5158 拍板 C 第 2 步)
+
+  `FilterArray` —— `['stage','=','won']`、`['and', […], […]]`、`[[…], […]]` —— 是**仅输入**的
+  授权糖。#5285 已在 spec 里把这件事写明(`data/filter.zod.ts`,`filter-array-declaration.test.ts`
+  钉住「被声明」且「`where` 不接受它」)。本次是拍板 C 的第 2 步:让**运行时**与那份声明一致。
+
+  ## 改了什么
+
+  进入运行时的门有两扇,过去只有一扇按契约读:
+
+  | 门                                                                                                | 改前                                                                                                                               | 改后                                                                                            |
+  | ------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
+  | **Door 1** —— 协议/HTTP 面(`metadata-protocol`)                                                   | `isFilterAST` → `parseFilterAST`,不可下沉的数组答 `400 INVALID_FILTER`                                                             | 不变                                                                                            |
+  | **Door 2** —— 进程内 engine 直调(`ObjectQL.find`/`findOne`/`count`/`aggregate`/`update`/`delete`) | 数组**原样**透传给驱动                                                                                                             | 走**同一条缝**:`isFilterAST` → `parseFilterAST` 下沉为 `FilterCondition`,不可下沉的数组响亮拒收 |
+  | 四驱动(`driver-sql`、继承它的 `driver-sqlite-wasm`、`driver-memory`、`driver-mongodb`)            | 各自带**第二套过滤器编译器**,包括一种**中缀**方言(`[condA, 'or', condB]`)—— 没有任何 schema 声明过它,`parseFilterAST` 也表达不了它 | 数组方言删除;数组到达驱动即 `INVALID_FILTER` / 400                                              |
+
+  一个查询两套编译器正是 ADR-0053 D-A1 禁止的分叉,而且它已经产生了真实的产品分叉:cloud 的
+  `RemoteTransport.buildWhereSQL` 自 cloud#1075 起对**同一输入**响亮拒收,`driver-sql` 却编译它。
+  删掉方言后两侧自然合流。
+
+  ## 授权面:零变化
+
+  `FilterBuilder`(`@objectstack/client`)产出的元组与 `['and', ...]` 组、React block 的
+  `filters` prop、wire 的 `$filter` 面、showcase 的授权点 —— **全部原样工作**,因为下沉正是
+  这些形状本来的用途。wire 契约逐字节不变(Door 1 的行为未改)。
+
+  ## ⚠️ 可观察的行为变更
+
+  1. **中缀连接不再被编译。** `where: [condA, 'or', condB]` 过去只有驱动认识,现在在 engine 门被拒收。
+     声明的写法是前缀组:`['or', condA, condB]` —— 语义相同,`parseFilterAST` 有它的下沉。
+  2. **`findOne({ where: [] })` 现在抛错。** `[]` 的含义**没有变**(仍是「无过滤」,`find`/`count`
+     照旧返回/计数全部行)。变的是 `findOne` 终于**看得见**这一点:未下沉的 `[]` 过去被
+     `requireFindOnePredicate` 当作「驱动自己去解释的表达式树」放行,于是 `limit: 1` 落在整张表上,
+     返回**任意一行** —— 正是 #4419 要挡的缺陷,活在 #4419 自己的守卫里面。
+  3. **不可下沉的数组在 engine 门拒收,不再由驱动拒收。** 形状与操作符词表相同(`isFilterAST` 同一套),
+     变的是消息来自调用点、带上调用方自己的值,以及明说「过滤器没有被应用,否则会返回**未过滤**的结果集」。
+  4. **驱动直调者(不经 engine)受影响。** `SqlDriver` / `InMemoryDriver` / `translateFilter` 是公开
+     导出;把数组 `where` 直接喂给它们的调用方需要改为先 `parseFilterAST(...)` 再传,或改走 ObjectQL。
+     注意 `QueryAST.where` 的 `FilterCondition` 是索引签名类型,数组对它是**可赋值**的 —— 类型层从未
+     挡住这个输入,所以拒收必须在运行时。
+  5. **`driver-mongodb` 的 `createdAt` → `created_at` 字段别名随方言一起消失。** 它只存在于数组路径
+     (`mapFieldName`,仅被已删除的 `translateComparison` 调用),对象路径从未应用过它。消费端别名按
+     AGENTS.md PD #12 是债务而非模式,故不再补回:请写声明的字段名 `created_at`。
+
+  ## 删除的代码面
+
+  - `SqlDriver.applyFilters` 的数组遍历分支,及其比较发射器 `protected applyAstComparison`(约 220 行)
+  - `InMemoryDriver.convertToMongoQuery` 的 legacy array 分支(约 62 行)
+  - `driver-mongodb` `mongodb-filter.ts` 的 `translateArrayFilter` / `translateComparison` / `mapFieldName`(约 140 行)
+  - `driver-sqlite-wasm` 无自有实现,随 `SqlDriver` 继承变更
+
+  `[]` 在每一层的读法**都不变**:engine 删键、`parseFilterAST([])` 为 `undefined`、三个驱动都提前返回。
+
+### Patch Changes
+
+- 06ba036: feat(drivers): `@objectstack/driver-turso` 迁回本仓并公开发布，五个 driver 统一收进 `packages/drivers/` (#4645)
+
+  `TursoDriver` 一直以 `extends SqlDriver` 的方式**跨仓库继承**本仓的类，自己却住在闭源的
+  `objectstack-ai/cloud`（`publishConfig: restricted`）。而本仓的 runtime 早就把 turso 当一等
+  公民——`http-dispatcher.ts` 里环境 provisioning 的偏好顺序第一位就是它，`POST /cloud/environments`
+  的 `driver` 参数示例是 `memory | turso`，`objectql/src/engine.ts` 还带着一段 turso 专属的瞬时
+  `fetch failed` 重试。开源侧的代码路径引用着一个自己仓里既测不到也 grep 不到的 driver，闭源侧则
+  在每次 pin bump 时追赶父类的重构。维护者裁定把核心迁回本仓、公开 Apache-2.0 发布。
+
+  **新包 `@objectstack/driver-turso`（`packages/drivers/driver-turso`，Apache-2.0，`access: public`）**
+  带着它在 cloud 的全部实现与测试落地：`TursoDriver`（local / replica / remote 三种传输模式）、
+  `RemoteTransport`（纯 `@libsql/client` 走 HTTP/WebSocket，无原生依赖，可跑 serverless/edge）、
+  驱动的 spec/Studio 元数据，以及 15 个测试文件 538 条断言——全部 hermetic，默认 CI 下不碰网络、
+  不要凭据（remote 面走包内的 sqlite stub）。
+
+  **留在 cloud（不随迁）**：按租户路由的 `multi-tenant.ts`（云产品差异化能力）及其 schema、
+  `vector-poc.test.ts`。因此本包的 barrel **不再导出** `createMultiTenantRouter` /
+  `MultiTenantConfig` / `MultiTenantRouter`，也不导出多租户 schema——它们从来不是这个 driver 的
+  一部分，只是曾经同包而已。
+
+  **目录重组**：五个 `IDataDriver` 实现（`driver-memory` / `driver-mongodb` / `driver-sql` /
+  `driver-sqlite-wasm` + 迁入的 `driver-turso`）现在都住在 `packages/drivers/`，
+  `knowledge-*` 与 `embedder-*` 留在 `packages/plugins/`。四个存量包**内容零改动**，只有
+  `repository.directory` 随目录更新——包名、入口、导出面、行为全部不变，消费者无需改动任何 import。
+
+  这也把 turso 交给了本仓的仓库级守卫：`check:driver-conformance` 从磁盘发现 driver 包，
+  迁入即入矩阵（5 drivers × 5 case-sets）。它的 temporal 两格是真绿（local 与 remote 双面套件），
+  filter 组合语义与两个分页 case-set 记为 measured DEBT——remote 传输自带一套 `buildWhereSQL` 与
+  `LIMIT`/`OFFSET` 拼装，是独立实现，"继承所以没问题"正是这些共享套件存在来证伪的假设。
+  补齐工作跟踪在 #5590。
+
+- 71f205d: fix(driver-mongodb): 空 `$and` / `$or` / `$not` 按布尔单位元归约,非 filter 节点先响亮拒收 (#5239)
+
+  `translateFilter` 过去把组合子数组**原样透传**给 MongoDB。而 MongoDB 对空数组既不答
+  TRUE 也不答 FALSE,是第三种行为:**直接拒绝整条查询**(`$and/$or/$nor must be a
+nonempty array`)。于是 `{ $and: [] }` 与 `{ $or: [] }` 一路走到 `find` /
+  `countDocuments` / `updateMany` / `deleteMany`,变成一个不带 ADR-0112 错误码的服务端
+  异常 —— 而 `driver-sql`(#5134 / PR #5243)、`driver-memory`、`formula` 三家早已按单位
+  元作答。
+
+  改成与它们同一套**结构性三值归约**:先把整棵 filter 树判成 `true` / `false` /
+  `clause`,再据此产出。空 `$and` 归约为 TRUE(不产出条件),空 `$or` 归约为 FALSE 并产出
+  一个**真实的零行条件** `{ _id: { $in: [] } }` —— 关键在于「什么都不产出」等于 `{}`,而
+  `find` / `updateMany` / `deleteMany` 把 `{}` 读作**全部文档**,方向正好相反。`{}` 作为
+  `$or` 的分支仍是 TRUE 析取项,`{ $not: {} }` 仍是零行,这两条 MongoDB 本来就与布尔代数
+  一致,所以归约按结构做而不是只判 `length === 0`。发出的每个 `$and` / `$or` 数组因此都保
+  证非空。
+
+  **同一改动里的形状拒收**,顺序是先拒收后归约:单位元把「这个节点没有谓词」读作「匹配全部
+  文档」,所以空节点必须只有一个成因。改前实测,本驱动这一格比 `driver-sql` 当年更糟 ——
+  `{ $or: [new Date()] }` 译成 `{ $or: [{}] }`,即**每一份文档**;`{ $or: 'x' }` 与
+  `{ $not: null }` 译成 `{}`,同样是每一份文档。`updateMany` / `deleteMany` 走的是同一个
+  translate 层,在那里「放宽到全部文档」不是行数不对而是数据丢失。现在这类操作数按
+  ADR-0112 以 `INVALID_FILTER` / `status: 400` 拒收,并在消息里点出位置
+  (`filter.$or[0]`)。`Date` / `RegExp` / class 实例都满足 `typeof x === 'object'` 却枚举
+  为空,故判定按**原型**而非 `typeof`。
+
+  `packages/spec` 侧只动文档:`FilterConditionSchema` 的契约 TSDoc 写明 `$not` 的
+  **NULL-safe** 语义(#5146 维护者拍板 —— 被比较列为 NULL 的行不满足被否定的条件,应当被
+  返回,即 `NOT (…) OR col IS NULL`),并在 `filter-logic-conformance.ts` 记下三族已裁定但
+  **尚未进表**的 case 及其实测矩阵。无运行时行为变化,无 API 变化。
+
+- 9c5abf4: fix(driver-sql,driver-memory,driver-mongodb): refuse out-of-contract filter input at the door instead of answering it differently per backend (#5347, #5348)
+
+  Two shapes the Filter Protocol never declared were reaching the drivers, and
+  every driver ANSWERED them — with a different answer. Both are now refused with
+  `INVALID_FILTER` / 400, in the ADR-0112 envelope every sibling filter refusal
+  already speaks.
+
+  ## `$null` with a non-boolean comparand — a behaviour change you can observe
+
+  `FieldOperatorsSchema` declares `$null: z.boolean()`. A non-boolean was read by
+  default branches hung on opposite sides, so one filter meant opposite things per
+  backend. Measured against one row with `stage: 'won'` (id 1) and one with
+  `stage: null` (id 2), on `{ stage: { $null: 'yes' } }`:
+
+  | backend                                     | read as                           | rows        |
+  | ------------------------------------------- | --------------------------------- | ----------- |
+  | driver-sql, driver-sqlite-wasm, Turso local | IS NULL (anything but `false`)    | `["2"]`     |
+  | driver-memory query path, driver-mongodb    | IS NOT NULL (anything but `true`) | `["1"]`     |
+  | driver-memory reference matcher             | no constraint at all              | `["1","2"]` |
+
+  **What changes for you:** a caller that today gets rows back for
+  `{ field: { $null: <non-boolean> } }` now gets a `400 INVALID_FILTER` naming the
+  operator, the field and the position. That includes calls working by truthy /
+  falsy coincidence — and the sharpest case is the STRING `"false"`, which is
+  truthy: it compiled to IS NULL on SQL and IS NOT NULL on the JS backends, i.e.
+  the opposite of what its author wrote it to mean, on at least one of them
+  whichever they meant. A JSON round-trip or generated metadata produces it
+  readily.
+
+  **The fix:** write the boolean. `{ field: { $null: true } }` for "has no value",
+  `{ field: { $null: false } }` for "has a value". Both are unchanged, on all four
+  backends, and so is every other operator. `$exists` is deliberately NOT tightened
+  here — it diverges on its own axis (what "exists" means for a null-valued key)
+  and is tracked separately.
+
+  ## An undeclared `$op` in a document position — silent empty set becomes a 400
+
+  `FilterConditionSchema` declares exactly three `$`-keys at a node
+  (`$and` / `$or` / `$not`); every other key is a field name. `driver-sql`
+  compiled the rest as COLUMNS, so `{ $where: '…' }`, `{ $nor: […] }`,
+  `{ $expr: … }` produced a predicate that matched nothing and reported nothing —
+  a caller could not tell "no rows matched" from "the filter never compiled". The
+  FIELD position had refused the same class of input since v16, so one driver gave
+  two answers depending on depth.
+
+  **What changes for you:** those filters now raise `400 INVALID_FILTER` instead of
+  returning `[]`. `driver-memory` already refused them; this brings `driver-sql`
+  (and `driver-sqlite-wasm`, which inherits it) into line. The three declared
+  combinators, their boolean identities (`$and: []` is TRUE, `$or: []` is FALSE)
+  and every legal filter compile byte-identically.
+
+  Both refusals are raised on the driver's validating walk rather than in its SQL
+  emitter, so a malformed node is refused regardless of whether a sibling
+  disjunct would have short-circuited the compile.
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [64cd010]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [b746aa0]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [08f93bc]
+- Updated dependencies [d9971d3]
+- Updated dependencies [eb3e650]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [02dc076]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [46365ab]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [c5adfe1]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/types@17.0.0-rc.4
+  - @objectstack/core@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Major Changes
diff --git a/packages/drivers/driver-mongodb/package.json b/packages/drivers/driver-mongodb/package.json
index f0e0f8c9e7..068c0271e2 100644
--- a/packages/drivers/driver-mongodb/package.json
+++ b/packages/drivers/driver-mongodb/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/driver-mongodb",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "MongoDB Driver for ObjectStack - Native document database driver via official mongodb client",
   "main": "dist/index.js",
diff --git a/packages/drivers/driver-sql/CHANGELOG.md b/packages/drivers/driver-sql/CHANGELOG.md
index b21327d23d..9738c51ca4 100644
--- a/packages/drivers/driver-sql/CHANGELOG.md
+++ b/packages/drivers/driver-sql/CHANGELOG.md
@@ -1,5 +1,795 @@
 # @objectstack/driver-sql
 
+## 17.0.0-rc.4
+
+### Minor Changes
+
+- 0f17114: fix(driver-sql,driver-memory,formula)!: `{ field: {} }` 一律拒收 —— 零个操作符的字段约束不再在四个后端有三个答案 (#5240)
+
+  `{ a: {} }`(一个字段,后面跟零个操作符)是 `FilterConditionSchema` 今天**声明合法**的形状,
+  而同一个 filter 在同仓四条路径上有三个答案:
+
+  | 路径                                | 改前                                                                                            | 改后                          |
+  | ----------------------------------- | ----------------------------------------------------------------------------------------------- | ----------------------------- |
+  | `driver-sql`,顶层 plain map         | 抛 `INVALID_FILTER`(#5041 的比较数闸门)                                                         | 抛 `INVALID_FILTER`(专用消息) |
+  | `driver-sql`,`$and`/`$or`/`$not` 内 | 遍历零个操作符 → 不产出任何 SQL → **TRUE(匹配全表)**                                            | 抛 `INVALID_FILTER`           |
+  | `driver-memory`                     | 实时路径经 mingo 变成「字段深等于空文档」;参考匹配器落到 `JSON.stringify` 结构相等 → 顺带 FALSE | 抛 `INVALID_FILTER`           |
+  | `@objectstack/formula`              | `keys.length === 0` 显式 fail-closed → FALSE                                                    | 抛 `INVALID_FILTER`           |
+
+  于是 `{ $or: [ { a: {} }, { b: 2 } ] }` 在 SQL 上编译成 `(b = 2)` —— 既不是「零约束即 TRUE」
+  该给的全表,也不是两个 JS 后端给的 FALSE,而是**子句被 knex 连同空分组一起丢掉**的结果;
+  而 `driver-sql` 自己内部就不自洽:同一个 `{ a: {} }` 写在顶层被响亮拒收,包进一层 `$or`
+  就变成静默的 TRUE。
+
+  维护者拍板取**拒收**(不取 TRUE、不取 FALSE):这个形状几乎必然是编写期事故 ——
+  筛选器记下了字段却没记下操作符,或生成的元数据把操作符弄丢了 —— 让它在编写期就炸,
+  好过在某个后端上安静地多返回或少返回几行。与 #5041 已在 driver-sql 顶层建立的先例一致,
+  本次只是把同一道闸门补进组合子内部。四个后端(第四个是继承 `SqlDriver` 的
+  `driver-sqlite-wasm`)现在给出同一个 `INVALID_FILTER` / 400,消息里指名出事的位置
+  (如 `filter.$or[0].stage`)。
+
+  **⚠️ 可观察的行为变更 —— RLS `check` 求值路径。** `@objectstack/formula` 的
+  `matchesFilterCondition` 是 `plugin-security` 对 insert/update **后像**执行行级 `check`
+  的那条路径(没有查询可下推,这个求值器就是执行本身)。它改为抛出后,落在 #4775
+  「求不出值 = 该次操作失败」的既定姿态上。这不只是「拒绝得更响」——有一类结果直接翻转:
+
+  | `check` 策略                                    | 改前                                  | 改后                     |
+  | ----------------------------------------------- | ------------------------------------- | ------------------------ |
+  | `{ a: {} }`                                     | FALSE → 写入被拒(403)                 | 抛出 → 该次写入失败(400) |
+  | `{ $or: [ { a: {} }, { owner: '{userId}' } ] }` | FALSE 被另一析取项吸收 → 写入**放行** | 抛出 → 该次写入失败      |
+  | `{ $not: { a: {} } }`                           | `!false` → 写入**放行**               | 抛出 → 该次写入失败      |
+
+  后两行是**原本能成功、现在会失败**的写入。这是拍板的目的而非副作用:一条含
+  `{ field: {} }` 的权限规则,是一条作者弄丢了操作符的规则,它的含义不该取决于四个后端里
+  哪一个在求值。升级后请检查 `check`/`using` 策略里是否存在零操作符的字段约束——
+  错误消息会指名位置。
+
+  同一条改动也让 `@objectstack/driver-memory` 的两个过滤面(经 mingo 的实时查询路径,
+  与跨后端一致性套件所用的 `memory-matcher` 参考匹配器)第一次对这个形状给出同一个答案。
+
+  非空形状**逐字符不变**:普通比较、`$in`、`$or`/`$and` 组合、`$not` 的 #5146 NULL-safe 改写,
+  编译出的 SQL 文本与匹配结果都与改前相同;`{}`(零个键的**节点**,#5134 的布尔单位元)
+  与 `{ field: {} }` 是两个不同形状,前者的语义不受本次影响。
+
+  注:本次收紧的是**实现**。`packages/spec` 的 `FilterConditionSchema` 仍然声明这个形状合法
+  (非递归半边是 `z.record(z.string(), z.unknown())`),即实现现在比已声明的契约更严;
+  契约收窄与 `FILTER_LOGIC_CASES` 补条归 spec 车道另行处理。
+
+- c7406b0: fix(objectql,driver-sql,driver-memory,driver-mongodb)!: `FilterArray` 在 engine 门下沉,四驱动的数组方言删除 (#5158 拍板 C 第 2 步)
+
+  `FilterArray` —— `['stage','=','won']`、`['and', […], […]]`、`[[…], […]]` —— 是**仅输入**的
+  授权糖。#5285 已在 spec 里把这件事写明(`data/filter.zod.ts`,`filter-array-declaration.test.ts`
+  钉住「被声明」且「`where` 不接受它」)。本次是拍板 C 的第 2 步:让**运行时**与那份声明一致。
+
+  ## 改了什么
+
+  进入运行时的门有两扇,过去只有一扇按契约读:
+
+  | 门                                                                                                | 改前                                                                                                                               | 改后                                                                                            |
+  | ------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
+  | **Door 1** —— 协议/HTTP 面(`metadata-protocol`)                                                   | `isFilterAST` → `parseFilterAST`,不可下沉的数组答 `400 INVALID_FILTER`                                                             | 不变                                                                                            |
+  | **Door 2** —— 进程内 engine 直调(`ObjectQL.find`/`findOne`/`count`/`aggregate`/`update`/`delete`) | 数组**原样**透传给驱动                                                                                                             | 走**同一条缝**:`isFilterAST` → `parseFilterAST` 下沉为 `FilterCondition`,不可下沉的数组响亮拒收 |
+  | 四驱动(`driver-sql`、继承它的 `driver-sqlite-wasm`、`driver-memory`、`driver-mongodb`)            | 各自带**第二套过滤器编译器**,包括一种**中缀**方言(`[condA, 'or', condB]`)—— 没有任何 schema 声明过它,`parseFilterAST` 也表达不了它 | 数组方言删除;数组到达驱动即 `INVALID_FILTER` / 400                                              |
+
+  一个查询两套编译器正是 ADR-0053 D-A1 禁止的分叉,而且它已经产生了真实的产品分叉:cloud 的
+  `RemoteTransport.buildWhereSQL` 自 cloud#1075 起对**同一输入**响亮拒收,`driver-sql` 却编译它。
+  删掉方言后两侧自然合流。
+
+  ## 授权面:零变化
+
+  `FilterBuilder`(`@objectstack/client`)产出的元组与 `['and', ...]` 组、React block 的
+  `filters` prop、wire 的 `$filter` 面、showcase 的授权点 —— **全部原样工作**,因为下沉正是
+  这些形状本来的用途。wire 契约逐字节不变(Door 1 的行为未改)。
+
+  ## ⚠️ 可观察的行为变更
+
+  1. **中缀连接不再被编译。** `where: [condA, 'or', condB]` 过去只有驱动认识,现在在 engine 门被拒收。
+     声明的写法是前缀组:`['or', condA, condB]` —— 语义相同,`parseFilterAST` 有它的下沉。
+  2. **`findOne({ where: [] })` 现在抛错。** `[]` 的含义**没有变**(仍是「无过滤」,`find`/`count`
+     照旧返回/计数全部行)。变的是 `findOne` 终于**看得见**这一点:未下沉的 `[]` 过去被
+     `requireFindOnePredicate` 当作「驱动自己去解释的表达式树」放行,于是 `limit: 1` 落在整张表上,
+     返回**任意一行** —— 正是 #4419 要挡的缺陷,活在 #4419 自己的守卫里面。
+  3. **不可下沉的数组在 engine 门拒收,不再由驱动拒收。** 形状与操作符词表相同(`isFilterAST` 同一套),
+     变的是消息来自调用点、带上调用方自己的值,以及明说「过滤器没有被应用,否则会返回**未过滤**的结果集」。
+  4. **驱动直调者(不经 engine)受影响。** `SqlDriver` / `InMemoryDriver` / `translateFilter` 是公开
+     导出;把数组 `where` 直接喂给它们的调用方需要改为先 `parseFilterAST(...)` 再传,或改走 ObjectQL。
+     注意 `QueryAST.where` 的 `FilterCondition` 是索引签名类型,数组对它是**可赋值**的 —— 类型层从未
+     挡住这个输入,所以拒收必须在运行时。
+  5. **`driver-mongodb` 的 `createdAt` → `created_at` 字段别名随方言一起消失。** 它只存在于数组路径
+     (`mapFieldName`,仅被已删除的 `translateComparison` 调用),对象路径从未应用过它。消费端别名按
+     AGENTS.md PD #12 是债务而非模式,故不再补回:请写声明的字段名 `created_at`。
+
+  ## 删除的代码面
+
+  - `SqlDriver.applyFilters` 的数组遍历分支,及其比较发射器 `protected applyAstComparison`(约 220 行)
+  - `InMemoryDriver.convertToMongoQuery` 的 legacy array 分支(约 62 行)
+  - `driver-mongodb` `mongodb-filter.ts` 的 `translateArrayFilter` / `translateComparison` / `mapFieldName`(约 140 行)
+  - `driver-sqlite-wasm` 无自有实现,随 `SqlDriver` 继承变更
+
+  `[]` 在每一层的读法**都不变**:engine 删键、`parseFilterAST([])` 为 `undefined`、三个驱动都提前返回。
+
+- 4addd9d: feat(driver-sql)!: organization-scoped uniques are NULL-safe — `COALESCE(organization_id, '__global__')` key part + `unique: 'organization'` on declared indexes (ADR-0120 D3/D4, #5030)
+
+  SQL UNIQUE is NULL-distinct, so the `(organization_id, field)` composite #3696
+  introduced enforced **nothing** on rows whose organization is NULL — which on a
+  single-tenant stack (where the kernel injects the column and never fills it) is
+  **every row**: field-level `unique: true` was a silent no-op there, measured in
+  #5030. Per ADR-0120 D3, every organization-scoped unique now materializes its
+  organization key part as `COALESCE(organization_id, '__global__')`: NULL-organization
+  rows collapse into one platform bucket, unique among themselves; non-NULL rows
+  are untouched. Storage stays NULL — the sentinel exists only inside the index
+  key, and it is the same word the autonumber sequence table already uses
+  (`GLOBAL_TENANT`), so a constraint-violation error reads as "the platform
+  bucket collided", not as corrupt data.
+
+  What changes, concretely:
+
+  - **Field-level `unique: true`** (and the new explicit synonym
+    `'organization'`) on a tenant-scoped object → composite
+    `(COALESCE(tenantField, '__global__'), field)`. `unique: 'global'` and
+    tenant-less objects are unchanged.
+  - **Declared indexes gain the ADR-0120 D1 scope vocabulary at the driver**:
+    `unique: 'organization'` prepends the NULL-safe organization key part to the
+    listed columns (degrading to the listed columns on a tenant-less object; a
+    listed tenant column is made NULL-safe in place instead — the S6 respelling).
+    `unique: true` / `'global'` on a declared index stays **verbatim** — the
+    #3696 contract, now the `'global'` arm; the nine engine dedup/idempotency
+    keys keep their exact physical shape. (The spec/lint side of the vocabulary
+    lands separately via #4986; the driver deliberately merges first.)
+  - **Drift detection reads both sides through one normalization**
+    (the #4884 discipline, extended to the tenant key part): the physical
+    `COALESCE(organization_id, <literal>)` form is attributed to the column,
+    compared **literal-agnostically**, and recognised as the sync's own
+    vocabulary — a healthy database reports zero drift on every dialect.
+  - **Existing bare composites migrate through the ceremony (ADR-0120 D4)**:
+    `(organization_id, X) → (COALESCE(organization_id, '__global__'), X)`
+    surfaces as a `recreate_index` drift op — a pure tightening — gated by a
+    **duplicate pre-flight probe**. Clean probe → the op grades `safe` and dev
+    `autoMigrate: 'safe'` / a plain `os migrate apply` applies it. Duplicates
+    (data the void constraint wrongly admitted) → the op is **blocked** with a
+    per-group row report, the old index stays in place, and apply re-probes so
+    even `--allow-destructive` cannot drop a constraint whose replacement is not
+    creatable. Deduplicate, re-plan, apply.
+  - **`'__global__'` is reserved at the organization-minting seam**
+    (plugin-auth): an organization whose id or slug equals the sentinel is
+    rejected at creation with a prescriptive error (ADR-0120 D3 guardrail).
+
+  Migration note for operators: on databases with pre-existing
+  organization-composite uniques, the first `os migrate plan` after upgrading
+  shows one `recreate_index` per affected index. On healthy data it auto-applies
+  in dev and is a no-op content-wise; a blocked op means the #5030 defect
+  admitted real duplicate rows — resolve the listed rows first. MySQL < 8.0.13 /
+  MariaDB cannot express the functional key part: the driver degrades to the
+  bare composite, says exactly what is not enforced at `error` level, and keeps
+  reporting the tightening as drift for after the server upgrade.
+
+### Patch Changes
+
+- 28ad90e: feat(types,cloud-connection,lint,cli): ADR-0120 17.x 收尾 —— `isolated` 安装期姿态硬门(D5e)、D5c 重拼写 advisory、成文契约扫荡与三姿态 conformance (#5081)
+
+  ADR-0120 17.x 波的第三块,也是最后一块。前两块已在 main 上:#5212(driver 侧
+  D3+D4 —— `COALESCE(organization_id, '__global__')` 物化、drift 两侧同步、重复预检)
+  与 #5208(spec 词汇 `'organization'` + D5a/D5b lint)。本次补齐三件事:安装期的
+  姿态决策点、剩余的成文契约、以及把「一个 app 包跑遍三种姿态」从假设变成测试。
+
+  **D5e —— 装进 `isolated` 环境时的硬门。** 词汇本身是姿态无关的:作者说的是业务
+  边界(`'organization'` 一个组织一份 / `'global'` 整个安装一份),没有任何索引形状
+  读姿态。唯一的残留在一个方向上:`isolated` 下组织就是**不同客户**,此时 app 业务
+  对象上的 `'global'` 唯一既跨客户过度约束,又变成跨客户的存在性预言机(S10/S14)。
+  维护者裁定这是**硬门而非 advisory**:把带 `'global'` 唯一(非 `sys` 对象)的 app
+  装进 `isolated` 环境会**停下来并逐索引列出**,安装者(通常是 AI agent)要么确认它
+  确实是平台级的,要么改写为 `'organization'`;确认按 ADR-0104 attestation 风格
+  留痕在安装清单里(`InstalledManifestEntry.globalUniqueAttestation` —— 确认了什么、
+  谁确认的、何时、在哪个姿态下问的),**之后不复问**。
+
+  - 停下的安装**什么都不留**:先于 hot-register 和任何 ledger 写入,所以作者改完
+    元数据可以直接重试,不需要先卸载。
+  - 逐索引确认是有牙齿的:`confirmGlobalUniques` 收 `true` 或明确的 id 数组,只确认
+    其中一条仍会在剩下的那条上停住。
+  - 升级引入的**新**约束会被问,老的答案继续算数。
+  - 另一个姿态下给出的确认**不算同意** —— `isolated` 那个问题在 `single` 下从未被
+    问过,所以按「未确认」处理(唯一不会静默放行跨客户约束的方向)。
+  - ⛔ **永不做成启动期告警**(#4884 纪律)。boot 时的 rehydrate 不评估此门;门够不到
+    的两类存量 —— 门禁上线前的安装、装后姿态变更的环境 —— 由 `os doctor` 与
+    `os migrate plan` 的 advisory 形态覆盖。
+
+  判定里有三条是承重的,别「简化」掉:声明索引上的裸 `unique: true` **算**(D1 说它
+  就是 `'global'` 的位置式拼写,排除它等于让整个 17.x 可以靠拼写绕过);字段级
+  `true` **不算**(它是 `'organization'`,永久合法);`sys_`/`base_` 对象**不算**
+  (S5 那批引擎幂等键天然就是平台级的,每次安装都问一遍就是 #4884 的误报类)。
+
+  CLI: `os package install` 新增 `--confirm-global-uniques`,并把 409 渲染成可读的
+  逐条清单而不是一句 "Install failed (409)"。
+
+  **D5c —— 遗留手写组织复合索引的 advisory。** 新规则
+  `unique/legacy-organization-composite`:声明的唯一索引自己列出了组织列
+  (`{ fields: ['name','organization_id'], unique: true }`)—— 这是词汇出现之前手写
+  per-organization 的写法。它读起来像「每组织唯一」,物化出来却是普通复合索引,而
+  SQL UNIQUE 是 NULL-distinct 的:组织列为 NULL 的行上它**什么都不约束**(#5030),
+  在单组织部署上那就是每一行。改写成 `unique: 'organization'`(`fields` 原样保留,
+  driver 会把已列出的组织列**就地**变成 NULL-safe 形式)正是补上这个洞的动作。
+  **永远只是 advisory,永远不自动修**:老拼写永久合法、零强制 drift,而 opt-in 是
+  真实的物理收紧,要走 D4 的 `recreate_index` + 重复预检。
+
+  **D6 —— 成文契约扫荡。** `content/docs/data-modeling/indexing.mdx` 的
+  §Two ways to say "unique" 全节按新词汇重写(含 `os:check` 代码块);
+  `content/docs/protocol/objectql/schema.mdx` 的 §Uniqueness and tenancy 重写为
+  §Uniqueness and scope —— 其中那句「单租户部署不受影响,租户列是常量,复合索引
+  退化为单列索引」是 #5030 **证伪过的原话**,现已替换为 D3 的 NULL-safe 事实;
+  `content/docs/deployment/cli.mdx` 的 `replace_unique_index` / `recreate_index`
+  条目补上 NULL-safe 形状与重复预检;`content/docs/references/**` 经
+  `gen:schema && gen:docs` 再生成,未手改。
+
+  按 ADR-0120 Resolved #2 的非规范性引导(官方示例/脚手架/生成器在新代码中输出
+  显式拼写),`skills/objectstack-data/**` 的索引与校验规则整体扫过:声明索引一律
+  说清 scope,并新增一节完整讲 `'organization'` 的 NULL-safe 语义与「永远不写姿态」。
+  顺带修掉那里长期使用的 `tenant_id` —— 平台的列叫 `organization_id`。
+  `examples/**`、`create-objectstack` 模板与 `os generate` 经核查**根本没有声明任何
+  唯一约束**,故无可扫;这是核查结论,不是遗漏。
+
+  **三姿态 conformance(ADR §Acceptance tests)。** 同一个 fixture app 在
+  `single | group | isolated` 三姿态下启动,逐 S 行用**真实的违规插入**断言 enforcement
+  (S1/S2/S3/S4/S5/S6/S7/S8/S9/S11/S12),并逐姿态捕获物化出的索引键,断言三者
+  **逐字节相同** —— 「没有任何索引形状读姿态」这句话一旦有两者不同就是假的。相同性
+  断言配了一条正向断言(对着期望的键形状),这样「三次都什么都没建」不会读成「一致」。
+  外加 ADR 只要的那一条 transition smoke:在 `single` 下建库、`isolated` 下重新打开,
+  drift op 为零。
+
+  对既有部署的影响:除新增的安装期确认外,本次不改变任何已有物化行为。字段级
+  `unique: true` 一如既往合法。
+
+- 06ba036: feat(drivers): `@objectstack/driver-turso` 迁回本仓并公开发布，五个 driver 统一收进 `packages/drivers/` (#4645)
+
+  `TursoDriver` 一直以 `extends SqlDriver` 的方式**跨仓库继承**本仓的类，自己却住在闭源的
+  `objectstack-ai/cloud`（`publishConfig: restricted`）。而本仓的 runtime 早就把 turso 当一等
+  公民——`http-dispatcher.ts` 里环境 provisioning 的偏好顺序第一位就是它，`POST /cloud/environments`
+  的 `driver` 参数示例是 `memory | turso`，`objectql/src/engine.ts` 还带着一段 turso 专属的瞬时
+  `fetch failed` 重试。开源侧的代码路径引用着一个自己仓里既测不到也 grep 不到的 driver，闭源侧则
+  在每次 pin bump 时追赶父类的重构。维护者裁定把核心迁回本仓、公开 Apache-2.0 发布。
+
+  **新包 `@objectstack/driver-turso`（`packages/drivers/driver-turso`，Apache-2.0，`access: public`）**
+  带着它在 cloud 的全部实现与测试落地：`TursoDriver`（local / replica / remote 三种传输模式）、
+  `RemoteTransport`（纯 `@libsql/client` 走 HTTP/WebSocket，无原生依赖，可跑 serverless/edge）、
+  驱动的 spec/Studio 元数据，以及 15 个测试文件 538 条断言——全部 hermetic，默认 CI 下不碰网络、
+  不要凭据（remote 面走包内的 sqlite stub）。
+
+  **留在 cloud（不随迁）**：按租户路由的 `multi-tenant.ts`（云产品差异化能力）及其 schema、
+  `vector-poc.test.ts`。因此本包的 barrel **不再导出** `createMultiTenantRouter` /
+  `MultiTenantConfig` / `MultiTenantRouter`，也不导出多租户 schema——它们从来不是这个 driver 的
+  一部分，只是曾经同包而已。
+
+  **目录重组**：五个 `IDataDriver` 实现（`driver-memory` / `driver-mongodb` / `driver-sql` /
+  `driver-sqlite-wasm` + 迁入的 `driver-turso`）现在都住在 `packages/drivers/`，
+  `knowledge-*` 与 `embedder-*` 留在 `packages/plugins/`。四个存量包**内容零改动**，只有
+  `repository.directory` 随目录更新——包名、入口、导出面、行为全部不变，消费者无需改动任何 import。
+
+  这也把 turso 交给了本仓的仓库级守卫：`check:driver-conformance` 从磁盘发现 driver 包，
+  迁入即入矩阵（5 drivers × 5 case-sets）。它的 temporal 两格是真绿（local 与 remote 双面套件），
+  filter 组合语义与两个分页 case-set 记为 measured DEBT——remote 传输自带一套 `buildWhereSQL` 与
+  `LIMIT`/`OFFSET` 拼装，是独立实现，"继承所以没问题"正是这些共享套件存在来证伪的假设。
+  补齐工作跟踪在 #5590。
+
+- d9971d3: fix(driver-sql): `$field` 跨字段比较改为按 ADR-0112 响亮拒绝,不再抛裸 TypeError
+
+  `{ amount: { $gt: { $field: 'budget' } } }`(spec `FieldReferenceSchema`,由 `compileCelToFilter` 在转译含字段间比较的 CEL 权限/RLS 规则时产出)此前被 SqlDriver 当作**绑定值**交给驱动,sqlite 抛出无 `code`、无 `status` 的裸 `TypeError` —— 落在 `INVALID_FILTER` 信封之外,到客户端表现为不透明的服务端错误。更隐蔽的是列表位置:`$in` / `$between` 里的 `$field` 成员连报错都没有,直接静默返回零行。
+
+  现在两者都以完整信封拒绝(`error.code = INVALID_FILTER`、HTTP 400、无 `[sql-driver]` 前缀),报错点名字段、运算符与被引用字段,并说明跨字段比较**当前仅内存求值路径(`matchesFilter`)支持**。三个比较发射点统一处理,Filter Protocol 与数组三元组两种写法得到同一答案。
+
+  同一处闸门补上了 issue 指出的通用臂:**已知运算符 + 无法绑定的值形态**(标量比较位上的普通对象 / 数组)此前同样是裸 `TypeError`,现在也返回 `INVALID_FILTER`。`$in` / `$nin` / `$between` 的正常数组绑定不受影响。
+
+  `FieldReferenceSchema` 声明保留,JSDoc 补注执行支持面(内存求值 ✅ / SQL 下推 ❌ 响亮拒绝);SQL 列对列编译实现见 #5222。
+
+- 2ddba89: fix(tenancy): eight sites answered "is this deployment multi-org?" with the demoted `OS_MULTI_ORG_ENABLED` (#5262)
+
+  ADR-0105 D1 made `OS_TENANCY_POSTURE` the authoritative knob and demoted
+  `OS_MULTI_ORG_ENABLED` to a back-compat _input_ of `resolveTenancyPosture()`.
+  A deployment configured the documented way — `OS_TENANCY_POSTURE=isolated` (or
+  `group`), legacy boolean unset — therefore reads `false` from
+  `resolveMultiOrgEnabled()` while running a fully mounted organization wall.
+  #5233 corrected two sites in `plugin-auth`; a census found eight more, all
+  written before that function's doc comment was corrected. Third recurrence of
+  the shape (cloud#1020, #5233).
+
+  Each site was judged separately for **which** posture answers its question —
+  what the operator REQUESTED, or what the `tenancy` service reports is actually
+  IN FORCE — rather than converted mechanically:
+
+  - `objectql` `SchemaRegistry` — the env-derived multi-tenant default. Reads the
+    REQUESTED posture (it is constructed below the kernel, with no service
+    registry to ask). The `organization_id` column was always provisioned; what
+    diverged is its INDEX, so a posture-only deployment ran the Layer 0 wall's
+    hottest predicate unindexed while SecurityPlugin compiled that same wall.
+  - `plugin-dev` — whether to load the enterprise `@objectstack/organizations`.
+    REQUESTED posture, mirroring `serve.ts`: this branch is what mounts the wall,
+    so asking whether the wall is up would be circular. A posture-only dev stack
+    previously never loaded the package at all and served traffic unwalled. Its
+    diagnostic now names the posture that was requested instead of asserting
+    `OS_MULTI_ORG_ENABLED=true` at an operator who never set it.
+  - `runtime` `AppPlugin` (inline seed + hot-reload seeder) — EFFECTIVE posture,
+    via the `tenancy` service. These ask "will the per-org replay run instead of
+    me?", and on an ADR-0093 D5 degraded boot that replay does not exist, so
+    keying on the request would defer to a replay that can never happen. Walled
+    deployments previously inline-seeded exactly the NULL-organization rows the
+    code's own comment exists to avoid.
+  - `cloud-connection` marketplace local install (install-time seed + rehydrate
+    heal) — EFFECTIVE posture, same reasoning. The install path is a write path:
+    a walled deployment wrote every sample row with no `organization_id`, landing
+    the app's data outside the wall its own reads apply.
+  - `driver-sql` `isMultiTenantMode()` — REQUESTED posture (a driver has no
+    kernel to ask, and a suppressed warning is the costlier error for a
+    diagnostic). It also no longer memoises into `_multiTenantMode`: that froze a
+    process-level fact into a per-instance verdict on whichever write landed
+    first. The gate now resolves live, which is affordable because
+    `auditMissingTenant` consults it only after the `tenantId` early-out.
+  - `cli` `os verify` — REQUESTED posture. This one produced a green verification
+    run over an unverified property: a posture-only deployment silently skipped
+    every multi-tenant proof and exited 0.
+
+  **No configuration change is needed anywhere.** Deployments setting only
+  `OS_MULTI_ORG_ENABLED=true` keep working unchanged — `resolveTenancyPosture()`
+  falls back to it — and the `OS_TENANCY_POSTURE=isolated` + `OS_MULTI_ORG_ENABLED=true`
+  belt-and-braces configuration stays valid. Deployments that set only
+  `OS_TENANCY_POSTURE` can now drop the redundant boolean. Single-org behaviour is
+  unchanged at every site; only the knob each one reads is corrected.
+
+- 9c5abf4: fix(driver-sql,driver-memory,driver-mongodb): refuse out-of-contract filter input at the door instead of answering it differently per backend (#5347, #5348)
+
+  Two shapes the Filter Protocol never declared were reaching the drivers, and
+  every driver ANSWERED them — with a different answer. Both are now refused with
+  `INVALID_FILTER` / 400, in the ADR-0112 envelope every sibling filter refusal
+  already speaks.
+
+  ## `$null` with a non-boolean comparand — a behaviour change you can observe
+
+  `FieldOperatorsSchema` declares `$null: z.boolean()`. A non-boolean was read by
+  default branches hung on opposite sides, so one filter meant opposite things per
+  backend. Measured against one row with `stage: 'won'` (id 1) and one with
+  `stage: null` (id 2), on `{ stage: { $null: 'yes' } }`:
+
+  | backend                                     | read as                           | rows        |
+  | ------------------------------------------- | --------------------------------- | ----------- |
+  | driver-sql, driver-sqlite-wasm, Turso local | IS NULL (anything but `false`)    | `["2"]`     |
+  | driver-memory query path, driver-mongodb    | IS NOT NULL (anything but `true`) | `["1"]`     |
+  | driver-memory reference matcher             | no constraint at all              | `["1","2"]` |
+
+  **What changes for you:** a caller that today gets rows back for
+  `{ field: { $null: <non-boolean> } }` now gets a `400 INVALID_FILTER` naming the
+  operator, the field and the position. That includes calls working by truthy /
+  falsy coincidence — and the sharpest case is the STRING `"false"`, which is
+  truthy: it compiled to IS NULL on SQL and IS NOT NULL on the JS backends, i.e.
+  the opposite of what its author wrote it to mean, on at least one of them
+  whichever they meant. A JSON round-trip or generated metadata produces it
+  readily.
+
+  **The fix:** write the boolean. `{ field: { $null: true } }` for "has no value",
+  `{ field: { $null: false } }` for "has a value". Both are unchanged, on all four
+  backends, and so is every other operator. `$exists` is deliberately NOT tightened
+  here — it diverges on its own axis (what "exists" means for a null-valued key)
+  and is tracked separately.
+
+  ## An undeclared `$op` in a document position — silent empty set becomes a 400
+
+  `FilterConditionSchema` declares exactly three `$`-keys at a node
+  (`$and` / `$or` / `$not`); every other key is a field name. `driver-sql`
+  compiled the rest as COLUMNS, so `{ $where: '…' }`, `{ $nor: […] }`,
+  `{ $expr: … }` produced a predicate that matched nothing and reported nothing —
+  a caller could not tell "no rows matched" from "the filter never compiled". The
+  FIELD position had refused the same class of input since v16, so one driver gave
+  two answers depending on depth.
+
+  **What changes for you:** those filters now raise `400 INVALID_FILTER` instead of
+  returning `[]`. `driver-memory` already refused them; this brings `driver-sql`
+  (and `driver-sqlite-wasm`, which inherits it) into line. The three declared
+  combinators, their boolean identities (`$and: []` is TRUE, `$or: []` is FALSE)
+  and every legal filter compile byte-identically.
+
+  Both refusals are raised on the driver's validating walk rather than in its SQL
+  emitter, so a malformed node is refused regardless of whether a sibling
+  disjunct would have short-circuited the compile.
+
+- f98fa65: fix(driver-sql): a fresh database no longer boots "drifted", and the drift
+  detector never points `--allow-destructive` at an index the framework created
+  (#4884)
+
+  Booting `examples/app-showcase` on a brand-new empty SQLite file printed two
+  `[schema-drift]` warnings before the server was even ready, both about the
+  ADR-0048 overlay indexes the same boot had just created. Both were false, and
+  one of them was dangerous:
+
+  > `[schema-drift] sys_metadata: index 'idx_sys_metadata_overlay_draft' UNIQUE
+(type, name, organization_id) carries ObjectStack's generated naming but
+matches no declared index (orphaned) — "os migrate apply --allow-destructive"
+to drop it.`
+
+  `idx_sys_metadata_overlay_draft` is the unique index enforcing **draft-overlay
+  uniqueness**. An operator following our own boot advice would have dropped a
+  live data-integrity guarantee to fix a problem that did not exist — and, worse,
+  learned to treat `--allow-destructive` as routine boot hygiene, which is exactly
+  what makes the _next_, real drift warning dangerous.
+
+  Three fixes, in the driver's detector only (no metadata declaration changed —
+  `sys-metadata.object.ts` documents its four-column `indexes[]` entry as _the
+  fallback shape for drivers without the runtime migration_, and that contract
+  still holds for the drivers that rely on it):
+
+  - **The index key is now read as written.** Introspection took the key from each
+    dialect's per-column catalogue view (`PRAGMA index_info`, `pg_attribute`,
+    `STATISTICS.COLUMN_NAME`), which describes an expression key as a NULL column
+    and nothing else. The canonical
+    `(type, name, organization_id, COALESCE(package_id,''))` overlay index
+    therefore arrived as three columns and was reported as a mismatch against its
+    own four-column declaration. SQLite and Postgres now parse the index
+    definition (`sqlite_master.sql` / `pg_get_indexdef`), MySQL reads
+    `STATISTICS.EXPRESSION` where the server has it, and `COALESCE(col, <literal>)`
+    is recognised as keying on `col` — which is what ADR-0048 uses it for: a plain
+    UNIQUE index treats NULLs as distinct, so package-less globals would not be
+    unique among themselves.
+  - **Partial predicates are captured.** A `WHERE`-restricted index is something
+    `syncDeclaredIndexes` can neither create nor rebuild, so the detector no
+    longer claims authorship of one, no longer calls it orphaned, and never
+    proposes a remedy it could not undo.
+  - **The driver keeps a ledger of the index DDL it executed.** An index this
+    process created through raw `execute()` — how `metadata-protocol`'s
+    `ensureOverlayIndex` issues its migration — is the framework's to manage. This
+    also covers the plain-index fallback the same migration takes on dialects that
+    reject partial indexes.
+
+  Genuine drift is unaffected: an orphaned generated index, a redefined declared
+  index and the #3696 legacy-unique replacement are all still detected, still
+  categorised exactly as before, and still remediable through `os migrate`.
+
+- 193cd5c: fix(driver-sql): 空 `$and`/`$or`/`$not` 按布尔单位元编译 —— `$or: []` 不再返回全表
+
+  **这是一处查询行为变更,且直接关系到 RLS。** `{ $or: [] }` 以前返回**整张表**,
+  现在返回**零行**。如果你的代码依赖了旧行为,它依赖的是一个 filter 旁路。
+
+  `applyFilterCondition` 把每个组合子都编译成一个 knex 分组回调,而 knex 对「一个子句
+  都没加进去的分组」不产出任何 SQL。于是「这个组是空的」和「这个组已被满足」编译成了
+  同一条查询。**丢弃子句不等于套用单位元**,而两个单位元的方向是相反的:
+
+  | 写法                 | 布尔代数                      | 旧编译    | 错的方向     |
+  | -------------------- | ----------------------------- | --------- | ------------ |
+  | `{ $and: [] }`       | TRUE → 全部行                 | 全表      | 碰巧正确     |
+  | `{ $or: [] }`        | FALSE → **零行**              | 全表      | **静默放松** |
+  | `{ $or: [{a}, {}] }` | `{}` 是 TRUE 析取项 → 全部行  | `(a = ?)` | 静默收紧     |
+  | `{ $not: {} }`       | `NOT TRUE ≡ FALSE` → **零行** | 全表      | **静默放松** |
+
+  `$and: []` 恰好正确的理由不是代码理解了单位元,而是「丢掉」在 AND 侧碰巧等价于
+  TRUE —— 同一段代码在 OR 与 NOT 侧就必然错。放松的那两格是安全相关的:`$or: []`
+  最常见的来源正是「本该有条件、但循环一个析取项都没填进去」的 RLS read scope,
+  把它当成全表意味着**本该看不到任何行的人拿到了整表**。
+
+  同仓另外两个后端(`formula` 的 `matchesFilterCondition`、`driver-memory`)三条
+  本来就都是对的,`driver-sql` 是唯一的例外;现在四个答案统一。
+
+  **配套的形状拒收(否则修复会变得更糟)。** 套用单位元的前提是「编译成空」只剩一个
+  成因。在此之前 `$or: [null]`、`$or: ['x']`、`$or: [[…]]`、`$or: [new Date()]`
+  同样会无痕消失;不先拦掉它们就上单位元,会把它们从「被静默忽略」**升级成「匹配所有
+  行」**,比原 bug 更坏。因此 `$and`/`$or` 的元素与 `$not` 的操作数现在必须是
+  **plain object** 的 filter 节点,否则按 ADR-0112 响亮拒收
+  (`INVALID_FILTER` / 400,报错指明出错位置,如 `filter.$or[1]`)。原型检查是关键
+  的一半:`Date`/`RegExp`/class 实例都满足 `typeof x === 'object'` 却枚举为空,
+  若被接受就会被读成 TRUE。同理 `$and: 'x'` 这类非数组操作数也不再被当成一个名为
+  `$and` 的字段列。
+
+  判定是**结构性**的(编译前先归约整棵树),而不是「编译完再问 knex 有没有产出」——
+  原缺陷本身就是后者那种观察,而观察分不清「因为本来就是空」和「因为有东西没编译
+  出来」。结构判定没有这个盲区,并且保证编译器打开的每个分组都至少收到一条子句,
+  knex 再没有机会静默丢弃一个组。
+
+  非空的 `$and`/`$or`/`$not` 编译方式完全未变。
+
+- 5aae790: fix(driver-sql): `$not` 改为 NULL-safe —— 被比较列为 NULL 的行不再被否定条件静默排除
+
+  **这是一处可观察的查询行为变更,且直接关系到 RLS 的可见集合。**
+  `{ $not: { stage: 'won' } }` 以前**不返回** `stage IS NULL` 的行,现在**返回**它们。
+  如果你的规则依赖了旧行为,它依赖的是「同一条规则在不同后端给出不同可见集合」。
+
+  SQL 是三值逻辑:`NULL = 'won'` 是 UNKNOWN,`NOT UNKNOWN` 仍是 UNKNOWN,而 `WHERE`
+  只保留 TRUE。于是 `applyFilterCondition` 编译出的裸 `NOT (stage = 'won')` 会把
+  「该列没有值」的行整批丢掉;同一条 filter 在 `driver-memory` 与 `formula` 的
+  `matchesFilterCondition` 上是普通的两值 JS 求值(`undefined !== 'won'` → 行匹配),
+  两边把这些行**都返回**。一个 spec 声明的算子,答案取决于跑它的是哪个驱动。
+
+  这不是「数目对不上」而已:权限规则里的 CEL `!expr` 经 `cel-to-filter.ts` 正是降解成
+  `{ $not: {…} }`,所以同一条 read scope 在 SQL 数据源与内存数据源上准入的行集不同。
+  #5146 判定以 JS 家族的答案为准(2:1 的多数派;写 `!(stage == 'won')` 的人不会预期
+  「stage 为空的行被隐藏」),本次把 SQL 侧对齐过去。
+
+  **编译出来的形状。** `$not` 的操作数在取反之前先被改写成**全域(total)谓词** ——
+  永远是 TRUE 或 FALSE,不会是 UNKNOWN:
+
+  ```sql
+  -- 之前
+  not (`stage` = 'won')
+  -- 现在
+  not ((`stage` is not null) and (`stage` = 'won'))
+  ```
+
+  对 issue 里给出的扁平形状,这与 `NOT (…) OR col IS NULL` 完全等价。把守卫下推到
+  **每个叶子**而不是挂在 `NOT` 旁边,是为了在操作数嵌套时仍然正确:`$not` 里套一个
+  `$or` 时,顶层的 `OR col IS NULL` 会把 JS 家族排除的行重新放进来(某一列为 NULL、
+  但另一个析取分支成立的行)。
+
+  **守卫方向按算子逐个判定,不是一刀切。** `{ $not: { a: { $ne: 5 } } }` 的语义是
+  「a 就是 5」,两个 JS 后端都把 NULL 行排除在外;无条件加 `OR a IS NULL` 会把这些行
+  交回去 —— 正是本驱动反复付过学费的静默放松(#2704 / #5134)。因此
+  `$ne` / `$nin` / `$notContains` 用的是 `col IS NULL OR (…)`,`$eq` / `$in` /
+  `$gt` / `$contains` 一族用 `col IS NOT NULL AND (…)`,而 `$null` / `$exists` /
+  `$eq: null` / `$ne: null` 本来就是全域谓词,一个字节都不加。
+
+  **只有 `$not` 路径被改写。** 普通比较的 SQL 逐字符不变(`{ a: 1 }` 仍然是
+  `a = 1`),因此没有任何非否定谓词因此失去索引;`$not` 路径上的 `IS NOT NULL` 守卫
+  本身处在一个原本就不可 sargable 的 `NOT (…)` 里。
+
+  `#5134` / PR #5243 定下的布尔单位元(`{ $not: {} }` → 零行、`$not` of FALSE →
+  全部行、非 filter 节点的操作数按 ADR-0112 响亮拒收)全部保持不变;`{ field: {} }`
+  (#5240)也刻意不在此裁定 —— 它编译出的 SQL 与之前完全一致。
+
+  `driver-memory` 与 `formula` 无需改动,本次为三家各补了一组 pin 测试,把「值缺失
+  行在 `$not` 下的去留」钉在一起。跨驱动 conformance case(`FILTER_LOGIC_CASES`)与
+  契约 TSDoc 归 spec 车道,随 #5239 落地。
+
+- 07f1822: fix(driver-sql): `$ne` / `$nin` / `$notContains` 改为 NULL-safe;`$exists` 的非布尔比较值改为拒收
+
+  **这是一处可观察的查询行为变更,且直接关系到 RLS 的可见集合。**
+  `{ stage: { $ne: 'won' } }` 以前**不返回** `stage IS NULL` 的行,现在**返回**它们。
+  `$nin` 与 `$notContains` 同理。
+
+  ### 变更一:三个否定算子在 `$not` 之外也 NULL-safe(#5298)
+
+  #5146 已经把 `$not` 判定为 NULL-safe(PR #5296),但**只改了 `$not` 内部**;算子自身
+  携带否定的三个 —— `$ne` / `$nin` / `$notContains` —— 逐字符未变。于是留下一个使用者
+  可见的裂缝:`{ $not: { stage: 'won' } }` 三家一致,`{ stage: { $ne: 'won' } }` 仍然
+  分叉。
+
+  成因与 #5146 同源:SQL 是三值逻辑,`NULL <> 'won'` 是 UNKNOWN 而不是 TRUE,`WHERE`
+  只保留 TRUE;`driver-memory` 与 `formula` 的 `matchesFilterCondition` 用两值 JS 求值
+  (`undefined !== 'won'` 直接为真),把这些行**都返回**。2026-08-06 裁定取「包含无值行」
+  方向(与 #5146 同向),本次把 SQL 侧对齐过去。
+
+  ```sql
+  -- 之前
+  `stage` <> 'won'
+  `stage` not in ('won')
+  `stage` NOT LIKE '%won%' ESCAPE '\'
+  -- 现在
+  (`stage` is null or `stage` <> 'won')
+  (`stage` is null or `stage` not in ('won'))
+  (`stage` is null or `stage` NOT LIKE '%won%' ESCAPE '\')
+  ```
+
+  **统一用 OR 展开,不走方言等价物**(`IS DISTINCT FROM` / `IS NOT` / `<=>`),三条理由:
+  `NOT LIKE` 根本没有对应形式,走方言就必然要维护两种形状;SQLite 的写法依赖本仓并不
+  锁定的引擎版本(sql.js 与 libSQL 各自演进);实测 `EXPLAIN QUERY PLAN` 两种写法计划
+  完全相同 —— `<>` / `NOT IN` / `NOT LIKE` 改动前**本来就是全表扫描**,没有索引可失去,
+  也没有索引可赢回。
+
+  **正向比较一个字节都没动。** `{ a: 1 }` 仍然是 `a = 1`,`$in` 仍然是 `in (…)`,
+  `$gt` / `$contains` 一族同理,所以绝大多数普通查询的 SQL 形状不变。
+  `$ne: null` 也不变 —— 它是空值**谓词**(`IS NOT NULL`)而不是比较,「有任何值」对
+  一个没有值的行本来就是假。
+
+  **`$not` 路径不受影响。** `nullSafeNegationOperand` 的逐叶守卫按原样保留:它必须能在
+  操作数任意嵌套时通过 De Morgan 组合,这与叶子发射器自身是否全域是两个独立的正确性
+  来源,把它们耦合起来会让其中一个的回退静默破坏另一个。
+
+  ### 变更二:`$exists` 的非布尔比较值改为拒收(#5369,套用 #5347 裁定 A)
+
+  `FieldOperatorsSchema` 声明 `$exists: z.boolean()`,而从 `where` 到驱动之间没有任何
+  环节按它校验,所以非布尔值真的会到达发射器。到达之后各后端分叉方向相反:本驱动的
+  `opValue === false` 恒等判断把「除 false 以外的一切」读成 `IS NOT NULL`,`=== true`
+  的写法则把「除 true 以外的一切」读成 `IS NULL`。注意字符串 `"false"` 是**真值**,
+  所以它落在与作者本意**相反**的一侧 —— JSON 往返或 AI 生成的 scope 很容易产出它。
+
+  现在与 `$null` 的闸门并排,在 `reduceFilterKey` 的校验遍历里拒收,`INVALID_FILTER` /
+  400,信封与措辞同款。`{ $exists: true }` / `{ $exists: false }` 行为一字未变。
+
+  **发射器与极性表刻意不动。** 闸门落地后只有两个布尔值能到达它们,`opValue === false`
+  与 `value === false` 已经是穷尽的二选一。#5369 正文建议的「收紧为 `value === true`」
+  方向写反了:极性表回答的是「NULL 列是否**满足**该算子」,而 NULL 列恰恰在调用方要求
+  `$exists: false` 时满足它 —— `$null: true` 与 `$exists: false` 是同一个问题,两条
+  分支正确地互为镜像,而不是互为副本。
+
+  ### 相关
+
+  `driver-memory` / `driver-mongodb` 的对应半边按 #5499 冻结,本次零改动、既有一致性
+  断言全绿;`driver-turso` 的 remote transport 是独立编译器,归 #5903;
+  `service-analytics` 的 `filter-normalizer`(Cube 面)归本裁决第二批。
+
+- acf34e3: fix(drivers): refuse an `undefined` filter comparand instead of crashing (SQL) or silently answering `IS NULL` (Turso remote) (#6050)
+
+  **⚠️ 行为变更(升级说明在最后一节)。** 比较数位置上的 `undefined` 从「静默/崩溃」变为 `INVALID_FILTER` / 400 拒收。作者侧的修法是显式判空,或改用 `null` / `$null`。
+
+  ## 实测到的毛病
+
+  同一个 `TursoDriver`,同一条过滤器,答案取决于它是用哪个 `url` 构造的 —— 四行 fixture(`d` 在 1-2 有值、3-4 为 NULL),`origin/main` @ `cba7454df`:
+
+  | filter                                | LOCAL(继承 `SqlDriver`)          | REMOTE(`RemoteTransport`) |
+  | ------------------------------------- | -------------------------------- | ------------------------- |
+  | `{ d: undefined }`                    | 抛裸 knex `Undefined binding(s)` | `['3','4']`               |
+  | `{ d: { $eq: undefined } }`           | 抛裸 knex `Undefined binding(s)` | `['3','4']`               |
+  | `{ $not: { d: undefined } }`          | 抛裸 knex `Undefined binding(s)` | `['1','2']`               |
+  | `{ d: { $ne: undefined } }`           | `['1','2']`                      | `['1','2']`               |
+  | `{ $not: { d: { $ne: undefined } } }` | `[]`                             | `['3','4']`               |
+  | `{ d: { $in: [undefined] } }`         | 抛裸 knex `Undefined binding(s)` | `[]`                      |
+  | `{ d: { $gt: undefined } }`           | 抛裸 knex `Undefined binding(s)` | `[]`                      |
+
+  两个可分开的毛病:
+
+  **A —— 抛出的那几格没有 ADR-0112 信封。** knex 的 `Undefined binding(s) detected when compiling SELECT` 既没有 `code` 也没有 `status`,`mapDataError` 落默认分支,于是一条「调用方把 filter 写坏了」的错误以不透明 500 的形态到达客户端。#1116 / #4436 为这条通路清点过同类形态,唯独漏了这一格。
+
+  **B —— 守卫与它自己的发射器分裂。** `$ne` 发射器读 `coerced == null`(宽松,所以 `undefined` 编译成 `IS NOT NULL` —— 一条 TOTAL 谓词),而必须钉住这个发射器的两张极性表 `operatorIsNullTotal` / `nullValueSatisfiesOperator` 读 `=== null`(严格,于是判它「不 total」且「NULL 行满足它」)。`nullGuardForFieldSpec` 因此把一条已经 total 的谓词包成 `d IS NULL OR d IS NOT NULL` —— 恒真 —— 取反后恒假,答 `[]`。这正是 #5298 立的不变量(每张极性表钉的是它自己发射器的拼写)在它自己的定义处被破坏。
+
+  ## 修法
+
+  一道闸,落在比较数进入**任何**发射器或守卫之前,两个毛病同闸消灭:knex 再也见不到 undefined 绑定,守卫与发射器对 undefined 的分歧变成**不可达**而不是「被修好」。
+
+  - `driver-sql`:闸落在 `reduceFilterKey` 的校验走查上(与 `$null` / `$exists` 的拒收并排),外加 `applyFilters` 的平铺映射分支 —— `{ d: undefined }` 进不了走查(`typeof undefined` 不是 `'object'`,构不成 `hasMongoOperators`),而它恰恰是这个 bug 最常见的拼写。两处共用一个函数。
+  - `driver-turso`:`buildWhereSQL` 入口做一次整棵子树的前置走查。必须前置,否则 `{ $not: { d: undefined } }` 会先把操作数交给 `nullSafeNegationOperand`(一个守卫)。
+  - 顺带把两侧的 `== null` / `|| === undefined` 拼写统一收严成 `=== null`(#5347 收紧 `$null` 臂时给的理由:宽松拼写在闸被挪走后会悄悄恢复回答一个没人裁决过的取值)。
+
+  拒收的位置逐个清点:直接比较数、单值算子的比较数(`$eq`/`$ne`/`$gt`/`$gte`/`$lt`/`$lte` 与 LIKE 族)、列表算子数组的**成员**(`$in`/`$nin`/`$between`)、以及嵌在 `$and`/`$or`/`$not` 里的以上各位。`$null` / `$exists` 的 `undefined` 保持它们**自己**的拒收措辞(比较数是声明的布尔量,那条消息更贴切 —— #5240「一个条件一种措辞」两个方向都适用)。两个驱动的拒收句子逐字一致。
+
+  ## ⛔ `null` 一字未动
+
+  `{ f: null }`、`{ $eq: null }` → `IS NULL`;`{ $ne: null }` → `IS NOT NULL`;`$null: true/false` 不变;`null` 仍是合法的 `$in` 成员。`null` 是声明过的比较数,拒的只是 JS 里与「没有这个键」不可区分的那个值。
+
+  ## 升级说明
+
+  如果你的进程内代码这样拼过 filter:
+
+  ```ts
+  // 之前:id 缺失时 —— 本地崩、远端静默匹配全环境行
+  await ql.find("deal", { where: { owner_id: ctx.user?.id } });
+  ```
+
+  现在会收到 `INVALID_FILTER` / 400,消息里带修法。两种正确写法:
+
+  ```ts
+  // 1) 显式判空 —— 键不存在就是「不约束」
+  const where: Record<string, unknown> = {};
+  if (ctx.user?.id !== undefined) where.owner_id = ctx.user.id;
+
+  // 2) 真的想要空值谓词 —— 写出来
+  await ql.find("deal", { where: { owner_id: null } }); // 或
+  await ql.find("deal", { where: { owner_id: { $null: true } } });
+  ```
+
+  `where` 整体缺席仍然是「没有过滤器」(`query?.where` 为 `undefined` 是它唯一合法的位置),不受影响。
+
+  ⚠️ 本次只覆盖 `driver-sql` 与 `driver-turso`(含 remote)。`driver-memory` / `driver-mongodb` 是 #5499 的投入冻结面,按裁决只测不改;`@objectstack/formula` 与 `service-analytics` 的 `read-scope-sql.ts` 对同一形状各有一种不同读法,实测记录在 #6125,留待单独裁决。
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [64cd010]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [b746aa0]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [08f93bc]
+- Updated dependencies [d9971d3]
+- Updated dependencies [eb3e650]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [02dc076]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [46365ab]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [c5adfe1]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/types@17.0.0-rc.4
+  - @objectstack/core@17.0.0-rc.4
+  - @objectstack/observability@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Major Changes
diff --git a/packages/drivers/driver-sql/package.json b/packages/drivers/driver-sql/package.json
index 5a1b888525..6f3e670f67 100644
--- a/packages/drivers/driver-sql/package.json
+++ b/packages/drivers/driver-sql/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/driver-sql",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "SQL Driver for ObjectStack - Supports PostgreSQL, MySQL, SQLite via Knex",
   "main": "dist/index.js",
diff --git a/packages/drivers/driver-sqlite-wasm/CHANGELOG.md b/packages/drivers/driver-sqlite-wasm/CHANGELOG.md
index f181150a35..b859e3fe88 100644
--- a/packages/drivers/driver-sqlite-wasm/CHANGELOG.md
+++ b/packages/drivers/driver-sqlite-wasm/CHANGELOG.md
@@ -1,5 +1,177 @@
 # @objectstack/driver-sqlite-wasm
 
+## 17.0.0-rc.4
+
+### Patch Changes
+
+- 06ba036: feat(drivers): `@objectstack/driver-turso` 迁回本仓并公开发布，五个 driver 统一收进 `packages/drivers/` (#4645)
+
+  `TursoDriver` 一直以 `extends SqlDriver` 的方式**跨仓库继承**本仓的类，自己却住在闭源的
+  `objectstack-ai/cloud`（`publishConfig: restricted`）。而本仓的 runtime 早就把 turso 当一等
+  公民——`http-dispatcher.ts` 里环境 provisioning 的偏好顺序第一位就是它，`POST /cloud/environments`
+  的 `driver` 参数示例是 `memory | turso`，`objectql/src/engine.ts` 还带着一段 turso 专属的瞬时
+  `fetch failed` 重试。开源侧的代码路径引用着一个自己仓里既测不到也 grep 不到的 driver，闭源侧则
+  在每次 pin bump 时追赶父类的重构。维护者裁定把核心迁回本仓、公开 Apache-2.0 发布。
+
+  **新包 `@objectstack/driver-turso`（`packages/drivers/driver-turso`，Apache-2.0，`access: public`）**
+  带着它在 cloud 的全部实现与测试落地：`TursoDriver`（local / replica / remote 三种传输模式）、
+  `RemoteTransport`（纯 `@libsql/client` 走 HTTP/WebSocket，无原生依赖，可跑 serverless/edge）、
+  驱动的 spec/Studio 元数据，以及 15 个测试文件 538 条断言——全部 hermetic，默认 CI 下不碰网络、
+  不要凭据（remote 面走包内的 sqlite stub）。
+
+  **留在 cloud（不随迁）**：按租户路由的 `multi-tenant.ts`（云产品差异化能力）及其 schema、
+  `vector-poc.test.ts`。因此本包的 barrel **不再导出** `createMultiTenantRouter` /
+  `MultiTenantConfig` / `MultiTenantRouter`，也不导出多租户 schema——它们从来不是这个 driver 的
+  一部分，只是曾经同包而已。
+
+  **目录重组**：五个 `IDataDriver` 实现（`driver-memory` / `driver-mongodb` / `driver-sql` /
+  `driver-sqlite-wasm` + 迁入的 `driver-turso`）现在都住在 `packages/drivers/`，
+  `knowledge-*` 与 `embedder-*` 留在 `packages/plugins/`。四个存量包**内容零改动**，只有
+  `repository.directory` 随目录更新——包名、入口、导出面、行为全部不变，消费者无需改动任何 import。
+
+  这也把 turso 交给了本仓的仓库级守卫：`check:driver-conformance` 从磁盘发现 driver 包，
+  迁入即入矩阵（5 drivers × 5 case-sets）。它的 temporal 两格是真绿（local 与 remote 双面套件），
+  filter 组合语义与两个分页 case-set 记为 measured DEBT——remote 传输自带一套 `buildWhereSQL` 与
+  `LIMIT`/`OFFSET` 拼装，是独立实现，"继承所以没问题"正是这些共享套件存在来证伪的假设。
+  补齐工作跟踪在 #5590。
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [b746aa0]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [06ba036]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [0f17114]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [c7406b0]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [d9971d3]
+- Updated dependencies [eb3e650]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [46365ab]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [c5adfe1]
+- Updated dependencies [26e1029]
+- Updated dependencies [4addd9d]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [2ddba89]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [9c5abf4]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [f98fa65]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [193cd5c]
+- Updated dependencies [5aae790]
+- Updated dependencies [07f1822]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [acf34e3]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/driver-sql@17.0.0-rc.4
+  - @objectstack/core@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Patch Changes
diff --git a/packages/drivers/driver-sqlite-wasm/package.json b/packages/drivers/driver-sqlite-wasm/package.json
index 7340cd1039..181499ed5d 100644
--- a/packages/drivers/driver-sqlite-wasm/package.json
+++ b/packages/drivers/driver-sqlite-wasm/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/driver-sqlite-wasm",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "WASM SQLite Driver for ObjectStack — runs in browser/WebContainer (StackBlitz) without native bindings",
   "keywords": [
diff --git a/packages/drivers/driver-turso/CHANGELOG.md b/packages/drivers/driver-turso/CHANGELOG.md
index 85fce94889..3bf64a2023 100644
--- a/packages/drivers/driver-turso/CHANGELOG.md
+++ b/packages/drivers/driver-turso/CHANGELOG.md
@@ -1,5 +1,432 @@
 # @objectstack/driver-turso
 
+## 17.0.0-rc.4
+
+### Minor Changes
+
+- 06ba036: feat(drivers): `@objectstack/driver-turso` 迁回本仓并公开发布，五个 driver 统一收进 `packages/drivers/` (#4645)
+
+  `TursoDriver` 一直以 `extends SqlDriver` 的方式**跨仓库继承**本仓的类，自己却住在闭源的
+  `objectstack-ai/cloud`（`publishConfig: restricted`）。而本仓的 runtime 早就把 turso 当一等
+  公民——`http-dispatcher.ts` 里环境 provisioning 的偏好顺序第一位就是它，`POST /cloud/environments`
+  的 `driver` 参数示例是 `memory | turso`，`objectql/src/engine.ts` 还带着一段 turso 专属的瞬时
+  `fetch failed` 重试。开源侧的代码路径引用着一个自己仓里既测不到也 grep 不到的 driver，闭源侧则
+  在每次 pin bump 时追赶父类的重构。维护者裁定把核心迁回本仓、公开 Apache-2.0 发布。
+
+  **新包 `@objectstack/driver-turso`（`packages/drivers/driver-turso`，Apache-2.0，`access: public`）**
+  带着它在 cloud 的全部实现与测试落地：`TursoDriver`（local / replica / remote 三种传输模式）、
+  `RemoteTransport`（纯 `@libsql/client` 走 HTTP/WebSocket，无原生依赖，可跑 serverless/edge）、
+  驱动的 spec/Studio 元数据，以及 15 个测试文件 538 条断言——全部 hermetic，默认 CI 下不碰网络、
+  不要凭据（remote 面走包内的 sqlite stub）。
+
+  **留在 cloud（不随迁）**：按租户路由的 `multi-tenant.ts`（云产品差异化能力）及其 schema、
+  `vector-poc.test.ts`。因此本包的 barrel **不再导出** `createMultiTenantRouter` /
+  `MultiTenantConfig` / `MultiTenantRouter`，也不导出多租户 schema——它们从来不是这个 driver 的
+  一部分，只是曾经同包而已。
+
+  **目录重组**：五个 `IDataDriver` 实现（`driver-memory` / `driver-mongodb` / `driver-sql` /
+  `driver-sqlite-wasm` + 迁入的 `driver-turso`）现在都住在 `packages/drivers/`，
+  `knowledge-*` 与 `embedder-*` 留在 `packages/plugins/`。四个存量包**内容零改动**，只有
+  `repository.directory` 随目录更新——包名、入口、导出面、行为全部不变，消费者无需改动任何 import。
+
+  这也把 turso 交给了本仓的仓库级守卫：`check:driver-conformance` 从磁盘发现 driver 包，
+  迁入即入矩阵（5 drivers × 5 case-sets）。它的 temporal 两格是真绿（local 与 remote 双面套件），
+  filter 组合语义与两个分页 case-set 记为 measured DEBT——remote 传输自带一套 `buildWhereSQL` 与
+  `LIMIT`/`OFFSET` 拼装，是独立实现，"继承所以没问题"正是这些共享套件存在来证伪的假设。
+  补齐工作跟踪在 #5590。
+
+- 05bb200: feat(driver-turso): remote 模式补上 canonical 时间列 backfill 通道(分批、可恢复、完成标记) (#5770)
+
+  `SqlDriver.backfillCanonicalDatetimes` / `backfillCanonicalTimes` 是 Knex 路径,
+  remote 模式的 DDL 与 CRUD 全部走 `@libsql/client`,永远到不了它们。于是
+  `canonicalDatetimeFields` / `canonicalTimeFields` 在 remote 恒空,
+  `needsLegacyDatetimeRepair` 恒为 true。在 `origin/main`(`d82b85fee`)上实测:
+
+  ```
+  canonicalDatetimeFields['probe']            -> undefined
+  needsLegacyDatetimeRepair('probe','at')     -> true
+  temporalFilterColumnSql('probe','at','"at"')
+    -> (case when typeof("at") in ('integer','real')
+          then strftime('%Y-%m-%dT%H:%M:%fZ', "at"/1000.0, 'unixepoch')
+          else coalesce(strftime('%Y-%m-%dT%H:%M:%fZ', "at"), "at") end)
+  ```
+
+  每一次对 `Field.datetime` / `Field.time` 的 filter 都编译成这个表达式 —— 正确,但
+  **不可索引**。local 跑完 backfill 能退回 `col >= ?`,remote 此前没有这个出口,
+  代价是永久的(cloud#1005 后果 A)。
+
+  **后果 B 实测比原单描述更尖锐。** `RemoteTransport.mapFieldTypeToSQL` 把时间列声明为
+  TEXT,#942 之前的 remote 写路径原样透传数字,于是 epoch 毫秒落盘成
+  `'1753660800000.0'`。共享修复表达式按 `typeof(col) in ('integer','real')` 分派,
+  TEXT 亲和列永不命中该支;`strftime` 也解析不了这串数字,`coalesce` 把原值还回来 ——
+  该行是修复表达式的**不动点**,永远转不过来,并且按 TEXT 比较。原单记为「任何 filter
+  都匹配不到」;实测是**更坏**的形态 —— `'1753660800000.0'` 字典序排在所有 `'2…'`
+  之前,所以该行既被自己所属的窗口漏掉,又被并不包含它的窗口命中:
+
+  ```
+  where at between '2025-07-01T…' and '2025-08-01T…'  -> ['ok']            (legacy 行丢失)
+  where at <= '2030-01-01T…'                          -> ['legacy','ok']   (不该命中却命中)
+  ```
+
+  ## 本次落地(维护者 2026-08-03 裁定的方案 1)
+
+  新增 `remote-canonical-backfill.ts` 与
+  `TursoDriver.backfillRemoteCanonicalTemporal()`,在 remote 的 `initObjects` /
+  `syncSchema` 之后自动运行 —— 与 local 在 `initObjects` 里调用 backfill 的位置对应:
+
+  - **分批**:每条 `UPDATE` 至多改 `batchSize` 行,借
+    `rowid IN (SELECT … LIMIT ?)` 子查询限量(`UPDATE … LIMIT` 需要 libSQL 不保证的
+    编译选项)。
+  - **可恢复**:不需要任何断点状态。WHERE 守卫本身就是断点 —— 它选中的正是尚未
+    canonical 的行,中断在任何位置都不回滚已转换的行,下次从余量继续;已收敛的列
+    重跑只花一条语句、零写入。
+  - **完成标记**:只有在收尾探针测到「两个阶段都无事可做」时才标 canonical,写进
+    `canonicalDatetimeFields` / `canonicalTimeFields` —— 与 local 完全相同的消费点
+    (`needsLegacyDatetimeRepair`),因此两种 transport 靠同一条规则拿回可索引形态。
+    被批次预算截断或报错的列**不标记**,保留读侧修复。
+  - **后果 B 的可解部分**:对元数据声明为 `Field.datetime` / `Field.time` 的列,把
+    纯数字文本按 `cast(col as real)` 喂回**驱动自己的**表达式(typeof 变成 'real',
+    于是走它原本的 integer/real 分支)。因此本仓不新增第二套 epoch 转换规则。
+  - **不可解残留如实记录**:只解释 1e12 ≤ v < 4102444800000(2001-09-09 ~ 2100-01-01)
+    的值。下界是为了让 epoch **秒**永不入界 —— 2100 年前的秒值最大约 4.1e9,若按毫秒
+    解释会把 `'1753660800'`(2025-07-28)静默改写成 1970-01-21,实测确认。界外的行
+    原样留在盘上并计入 `unresolvedEpochTextRows`,不猜。
+
+  方案 2(DDL 亲和性对齐)按裁定等 staging 存量探针另议,不在本次范围;方案 3(在
+  `@objectstack/driver-sql` 公共表达式里加启发式)维护者已否决 —— 上面的恢复限于
+  一次性迁移、且只作用于元数据声明为时间类型的列,与那条被否决的读路径启发式不是
+  一回事。
+
+  ## 正确性姿态不变(ADR-0053 D-B3 / cloud#1003)
+
+  backfill 是**性能出口,不是正确性前提**。读写路径不依赖它跑过:任何失败(远端不可
+  达、标识符非法、预算耗尽)都只导致该列不被标记、读侧继续带修复、答案照旧正确,
+  且不会让 boot 失败。新增 20 条用例覆盖两个后果、分批/断点续跑/失败中断、完成标记
+  的三个门、不可解残留、以及「标记与不标记答案一致」的 D-B3 断言。
+
+  `turso-remote-temporal-conformance.test.ts` 的两条 legacy sweep 现在显式清除
+  canonical 标记(与 driver-sql 的 `LegacyStorageDriver.forgetCanonical` 同一做法),
+  并断言修复确实仍在生效 —— 此前 remote 「未 backfill」是因为压根没有 backfill 而
+  **碰巧**成立,现在它是 fixture 必须自己声明的状态。
+
+### Patch Changes
+
+- d82b85f: fix(driver-turso): remote 模式拒收条件层的 `$`-算子键 —— 不再编译成静默空集/全表写 (#5769)
+
+  `RemoteTransport.buildWhereSQL` 只认 `$and` / `$or` / `$not` 三个组合算子;条件
+  层其余任何 `$` 开头的键都掉进**字段路径**,被双引号引成一个**列名**。在
+  `origin/main`(`5c94f833c`)上用捕获客户端 + 三行 fixture 实测:
+
+  ```
+  { $eq: 'won' }                 → SELECT * FROM "deal" WHERE "$eq" = ?         → []
+  { $gt: 5 }                     → SELECT * FROM "deal" WHERE "$gt" = ?         → []
+  { $where: 'return true' }      → SELECT * FROM "deal" WHERE "$where" = ?      → []
+  { $and: 'x' }                  → SELECT * FROM "deal" WHERE "$and" = ?        → []
+  { $or: [{}, { $where: 'x' }] } → SELECT * FROM "deal"(整句没有 WHERE)        → 全部三行
+  ```
+
+  前四行是**静默空结果集**:SQLite 的向后兼容规则把「解析不到列的双引号标识符」
+  降级成字符串字面量,于是语句编得出、跑得通、一行不匹配 —— 和「确实没有匹配的
+  行」在调用侧完全无法区分(在关掉该规则的构建上,`find()` 自己的 `no such column`
+  兜底也会把它吞成 `[]`,两条路一个答案)。
+
+  第五行不依赖任何方言怪癖,也是代价最大的一种:`{}` 是 `$or` 的 TRUE 单位元,
+  整组被吸收,连同它那个畸形兄弟已经编出来的子句一起被丢掉,语句**整个丢掉了
+  WHERE**。读路径上这是把过滤器本要排除的行原样交还;`deleteMany` / `updateMany`
+  上这是**全表写** —— 实测三行全部被一个一行都没点名的过滤器改写。
+
+  现在:条件层任何非 `$and`/`$or`/`$not` 的 `$` 键,在 find / findOne / count /
+  aggregate / deleteMany / updateMany 六个建 WHERE 的入口上一律以
+  `INVALID_FILTER` / 400 响亮拒收,且**不发出任何语句**。消息分两种 —— 是字段算子
+  写高了一层(`$eq`/`$gt`/…)就指路 `{ <字段名>: { <算子>: <值> } }`;协议根本没
+  声明的键(`$where`/`$nor`/`$expr`/`$elemMatch`)就点名拒收。声明正确但值不是数组
+  的 `$and` / `$or`(`{ $and: 'x' }`)同样落在这个闸里,按「需要条件数组」拒收 ——
+  它此前从两个 `Array.isArray` 判断底下漏进同一条字段路径,结局一模一样。
+
+  这条规则本来就是 objectstack#5348 的裁定,PR #5368 已在 `SqlDriver` 的校验遍历
+  (`reduceFilterKey`)落地,`driver-sqlite-wasm` 与 Turso **local** 继承。
+  `RemoteTransport` 是独立的过滤器编译器,什么都继承不到,所以同一个
+  `TursoDriver`、同一个过滤器,只因 `url` 不同就给两个答案,而且方向是反的:local
+  严、remote 松。本次补的正是这最后一面,新增的 local/remote 一致性用例把这条叉
+  钉死。
+
+  合法过滤器一个字节都没变:三个组合算子的嵌套、`$and: []` / `$or: []` / `$not: {}`
+  的布尔单位元、字段层算子、隐式相等、`IS NULL`,以及既有的六种拒收(未知字段算子、
+  不可绑定比较值、空算子映射、非节点子过滤器、非节点顶层 `where`、非布尔 `$null`)
+  各自的措辞,全部照旧。
+
+- 8a2ea6c: driver-turso: remote mode answers the NULL / no-value family the way local mode does
+
+  `TursoDriver` compiles filters two different ways: local (and replica) mode
+  inherits `SqlDriver.applyFilterCondition`, remote mode uses
+  `RemoteTransport.buildWhereSQL`, an independent emitter. The NULL rulings landed
+  only on the first, so ONE driver gave one filter two answers depending on the
+  `url` it was constructed with. Measured against a fixture with two valued rows
+  and two no-value rows:
+
+  | filter                          | local            | remote (before) |
+  | ------------------------------- | ---------------- | --------------- |
+  | `{ d: { $ne: 'v1' } }`          | rows 2,3,4       | row 2           |
+  | `{ d: { $nin: ['v1'] } }`       | rows 2,3,4       | row 2           |
+  | `{ d: { $notContains: 'v1' } }` | rows 2,3,4       | row 2           |
+  | `{ $not: { d: 'v1' } }`         | rows 2,3,4       | row 2           |
+  | `{ d: { $exists: 'yes' } }`     | `INVALID_FILTER` | rows 1,2        |
+
+  Remote mode now matches local on all five:
+
+  - **`$not` is NULL-safe** (#5146). Each leaf of the negated condition is made
+    total before the negation, so `NOT (…)` is TRUE or FALSE for every row instead
+    of vanishing into SQL's UNKNOWN. A row whose column has no value does not
+    satisfy the negated condition, so it IS returned.
+  - **`$ne`, `$nin` and `$notContains` are NULL-safe** (#5298), emitted as
+    `(col IS NULL OR <test>)`. `$ne: null` is unchanged and still compiles to
+    `IS NOT NULL` — polarity follows the comparand, not the operator's name — and
+    no positive comparison changes shape.
+  - **A non-boolean `$exists` comparand is refused** with `INVALID_FILTER` / 400
+    (#5369), as `$null` already was. `@objectstack/spec`'s `FieldOperatorsSchema`
+    declares `$exists` as a boolean, and the emitter's `=== false` test sent every
+    other value — including the truthy string `"false"` — to the `IS NOT NULL`
+    side. `$exists: true` / `$exists: false` are unchanged.
+
+  Why it matters beyond a row count: a CEL `!expr` in a permission rule lowers to
+  `{ $not: {…} }`, so this was one RLS read scope admitting different row sets per
+  connection mode. The `$ne` and `$not` cases are now enrolled in the shared
+  `FILTER_LOGIC_CASES` conformance table, which all eleven filter backends run.
+
+  **Upgrade note:** a query that relied on remote mode silently dropping no-value
+  rows from a negative filter will now see them. Spell that intent explicitly —
+  `{ $and: [{ d: { $ne: 'v1' } }, { d: { $null: false } }] }` — which is what it
+  already had to be on every other backend.
+
+- a58c0b5: fix(driver-turso): remote 分页读补齐确定性排序，与 local 面共用同一条规则
+
+  `TursoDriver` 在 remote 传输(`libsql://` / `https://` 等 URL)下的分页读不满足
+  `IDataDriver.find` 的确定性分页 MUST：`RemoteTransport.buildSelectSQL` 把调用方的
+  `orderBy` 原样拼进 SQL 后直接接 `LIMIT` / `OFFSET`，不追加任何唯一列，无序分页读
+  更是完全不排序。SQLite 不承诺并列行在两条语句之间排布一致，所以表一大、计划一变，
+  `ORDER BY status LIMIT 50 OFFSET 50` 翻页时就会有记录出现两次、另一条永远不出现 ——
+  每一页都是满的、每一行都合法，从任何单个响应里都看不出来。
+
+  同一个驱动的 local 面早已按 #4363 办事，于是一个驱动的两条传输对同一个分页查询给出
+  不同的排序保证，而传输模式只由 URL 决定。
+
+  修法是**复用**而不是复制：`TursoDriver.find` / `findOne` 现在通过继承来的
+  `SqlDriver.orderKeysFor()` 解析出完整排序键再交给传输层，三态规则只有一份实现 ——
+
+  | `orderBy` | 分页                | 结果                                       |
+  | --------- | ------------------- | ------------------------------------------ |
+  | 非空      | 任意                | 调用方的键 + `id`                          |
+  | 空        | 有 `limit`/`offset` | 单独 `id`                                  |
+  | 空        | 都没有              | 不加 ORDER BY（#4363 carve-out，原样保留） |
+
+  `findOne` 的语义一并保住：它的 `limit: 1` 由传输层自己注入，若在 `buildSelectSQL`
+  里判定就会被误读成「页大小为 1 的第一页」，从而给系统里最热的读加上
+  `ORDER BY id LIMIT 1` —— 正是让计划器放弃谓词自身索引的形状。
+
+  唯一列的判定沿用 local 面同样保守的前提：只有本驱动自己建的表才追加 `id`
+  (`RemoteTransport` 建表时无条件写入 `"id" TEXT PRIMARY KEY`)；不是自己建的表保持
+  原样并告警一次，绝不凭空发明排序列。
+
+- acf34e3: fix(drivers): refuse an `undefined` filter comparand instead of crashing (SQL) or silently answering `IS NULL` (Turso remote) (#6050)
+
+  **⚠️ 行为变更(升级说明在最后一节)。** 比较数位置上的 `undefined` 从「静默/崩溃」变为 `INVALID_FILTER` / 400 拒收。作者侧的修法是显式判空,或改用 `null` / `$null`。
+
+  ## 实测到的毛病
+
+  同一个 `TursoDriver`,同一条过滤器,答案取决于它是用哪个 `url` 构造的 —— 四行 fixture(`d` 在 1-2 有值、3-4 为 NULL),`origin/main` @ `cba7454df`:
+
+  | filter                                | LOCAL(继承 `SqlDriver`)          | REMOTE(`RemoteTransport`) |
+  | ------------------------------------- | -------------------------------- | ------------------------- |
+  | `{ d: undefined }`                    | 抛裸 knex `Undefined binding(s)` | `['3','4']`               |
+  | `{ d: { $eq: undefined } }`           | 抛裸 knex `Undefined binding(s)` | `['3','4']`               |
+  | `{ $not: { d: undefined } }`          | 抛裸 knex `Undefined binding(s)` | `['1','2']`               |
+  | `{ d: { $ne: undefined } }`           | `['1','2']`                      | `['1','2']`               |
+  | `{ $not: { d: { $ne: undefined } } }` | `[]`                             | `['3','4']`               |
+  | `{ d: { $in: [undefined] } }`         | 抛裸 knex `Undefined binding(s)` | `[]`                      |
+  | `{ d: { $gt: undefined } }`           | 抛裸 knex `Undefined binding(s)` | `[]`                      |
+
+  两个可分开的毛病:
+
+  **A —— 抛出的那几格没有 ADR-0112 信封。** knex 的 `Undefined binding(s) detected when compiling SELECT` 既没有 `code` 也没有 `status`,`mapDataError` 落默认分支,于是一条「调用方把 filter 写坏了」的错误以不透明 500 的形态到达客户端。#1116 / #4436 为这条通路清点过同类形态,唯独漏了这一格。
+
+  **B —— 守卫与它自己的发射器分裂。** `$ne` 发射器读 `coerced == null`(宽松,所以 `undefined` 编译成 `IS NOT NULL` —— 一条 TOTAL 谓词),而必须钉住这个发射器的两张极性表 `operatorIsNullTotal` / `nullValueSatisfiesOperator` 读 `=== null`(严格,于是判它「不 total」且「NULL 行满足它」)。`nullGuardForFieldSpec` 因此把一条已经 total 的谓词包成 `d IS NULL OR d IS NOT NULL` —— 恒真 —— 取反后恒假,答 `[]`。这正是 #5298 立的不变量(每张极性表钉的是它自己发射器的拼写)在它自己的定义处被破坏。
+
+  ## 修法
+
+  一道闸,落在比较数进入**任何**发射器或守卫之前,两个毛病同闸消灭:knex 再也见不到 undefined 绑定,守卫与发射器对 undefined 的分歧变成**不可达**而不是「被修好」。
+
+  - `driver-sql`:闸落在 `reduceFilterKey` 的校验走查上(与 `$null` / `$exists` 的拒收并排),外加 `applyFilters` 的平铺映射分支 —— `{ d: undefined }` 进不了走查(`typeof undefined` 不是 `'object'`,构不成 `hasMongoOperators`),而它恰恰是这个 bug 最常见的拼写。两处共用一个函数。
+  - `driver-turso`:`buildWhereSQL` 入口做一次整棵子树的前置走查。必须前置,否则 `{ $not: { d: undefined } }` 会先把操作数交给 `nullSafeNegationOperand`(一个守卫)。
+  - 顺带把两侧的 `== null` / `|| === undefined` 拼写统一收严成 `=== null`(#5347 收紧 `$null` 臂时给的理由:宽松拼写在闸被挪走后会悄悄恢复回答一个没人裁决过的取值)。
+
+  拒收的位置逐个清点:直接比较数、单值算子的比较数(`$eq`/`$ne`/`$gt`/`$gte`/`$lt`/`$lte` 与 LIKE 族)、列表算子数组的**成员**(`$in`/`$nin`/`$between`)、以及嵌在 `$and`/`$or`/`$not` 里的以上各位。`$null` / `$exists` 的 `undefined` 保持它们**自己**的拒收措辞(比较数是声明的布尔量,那条消息更贴切 —— #5240「一个条件一种措辞」两个方向都适用)。两个驱动的拒收句子逐字一致。
+
+  ## ⛔ `null` 一字未动
+
+  `{ f: null }`、`{ $eq: null }` → `IS NULL`;`{ $ne: null }` → `IS NOT NULL`;`$null: true/false` 不变;`null` 仍是合法的 `$in` 成员。`null` 是声明过的比较数,拒的只是 JS 里与「没有这个键」不可区分的那个值。
+
+  ## 升级说明
+
+  如果你的进程内代码这样拼过 filter:
+
+  ```ts
+  // 之前:id 缺失时 —— 本地崩、远端静默匹配全环境行
+  await ql.find("deal", { where: { owner_id: ctx.user?.id } });
+  ```
+
+  现在会收到 `INVALID_FILTER` / 400,消息里带修法。两种正确写法:
+
+  ```ts
+  // 1) 显式判空 —— 键不存在就是「不约束」
+  const where: Record<string, unknown> = {};
+  if (ctx.user?.id !== undefined) where.owner_id = ctx.user.id;
+
+  // 2) 真的想要空值谓词 —— 写出来
+  await ql.find("deal", { where: { owner_id: null } }); // 或
+  await ql.find("deal", { where: { owner_id: { $null: true } } });
+  ```
+
+  `where` 整体缺席仍然是「没有过滤器」(`query?.where` 为 `undefined` 是它唯一合法的位置),不受影响。
+
+  ⚠️ 本次只覆盖 `driver-sql` 与 `driver-turso`(含 remote)。`driver-memory` / `driver-mongodb` 是 #5499 的投入冻结面,按裁决只测不改;`@objectstack/formula` 与 `service-analytics` 的 `read-scope-sql.ts` 对同一形状各有一种不同读法,实测记录在 #6125,留待单独裁决。
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [b746aa0]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [06ba036]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [0f17114]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [c7406b0]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [d9971d3]
+- Updated dependencies [eb3e650]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [46365ab]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [c5adfe1]
+- Updated dependencies [26e1029]
+- Updated dependencies [4addd9d]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [2ddba89]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [9c5abf4]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [f98fa65]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [193cd5c]
+- Updated dependencies [5aae790]
+- Updated dependencies [07f1822]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [acf34e3]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/driver-sql@17.0.0-rc.4
+  - @objectstack/core@17.0.0-rc.4
+
 ## 6.9.0
 
 ### Patch Changes
diff --git a/packages/drivers/driver-turso/package.json b/packages/drivers/driver-turso/package.json
index d98e8956cd..5f285faa8a 100644
--- a/packages/drivers/driver-turso/package.json
+++ b/packages/drivers/driver-turso/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/driver-turso",
-  "version": "17.0.0-rc.2",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "Turso/libSQL Driver for ObjectStack — Edge-first SQLite with embedded replicas",
   "keywords": [
diff --git a/packages/formula/CHANGELOG.md b/packages/formula/CHANGELOG.md
index 4d80fe54b2..a72187e15b 100644
--- a/packages/formula/CHANGELOG.md
+++ b/packages/formula/CHANGELOG.md
@@ -1,5 +1,288 @@
 # @objectstack/formula
 
+## 17.0.0-rc.4
+
+### Minor Changes
+
+- 0f17114: fix(driver-sql,driver-memory,formula)!: `{ field: {} }` 一律拒收 —— 零个操作符的字段约束不再在四个后端有三个答案 (#5240)
+
+  `{ a: {} }`(一个字段,后面跟零个操作符)是 `FilterConditionSchema` 今天**声明合法**的形状,
+  而同一个 filter 在同仓四条路径上有三个答案:
+
+  | 路径                                | 改前                                                                                            | 改后                          |
+  | ----------------------------------- | ----------------------------------------------------------------------------------------------- | ----------------------------- |
+  | `driver-sql`,顶层 plain map         | 抛 `INVALID_FILTER`(#5041 的比较数闸门)                                                         | 抛 `INVALID_FILTER`(专用消息) |
+  | `driver-sql`,`$and`/`$or`/`$not` 内 | 遍历零个操作符 → 不产出任何 SQL → **TRUE(匹配全表)**                                            | 抛 `INVALID_FILTER`           |
+  | `driver-memory`                     | 实时路径经 mingo 变成「字段深等于空文档」;参考匹配器落到 `JSON.stringify` 结构相等 → 顺带 FALSE | 抛 `INVALID_FILTER`           |
+  | `@objectstack/formula`              | `keys.length === 0` 显式 fail-closed → FALSE                                                    | 抛 `INVALID_FILTER`           |
+
+  于是 `{ $or: [ { a: {} }, { b: 2 } ] }` 在 SQL 上编译成 `(b = 2)` —— 既不是「零约束即 TRUE」
+  该给的全表,也不是两个 JS 后端给的 FALSE,而是**子句被 knex 连同空分组一起丢掉**的结果;
+  而 `driver-sql` 自己内部就不自洽:同一个 `{ a: {} }` 写在顶层被响亮拒收,包进一层 `$or`
+  就变成静默的 TRUE。
+
+  维护者拍板取**拒收**(不取 TRUE、不取 FALSE):这个形状几乎必然是编写期事故 ——
+  筛选器记下了字段却没记下操作符,或生成的元数据把操作符弄丢了 —— 让它在编写期就炸,
+  好过在某个后端上安静地多返回或少返回几行。与 #5041 已在 driver-sql 顶层建立的先例一致,
+  本次只是把同一道闸门补进组合子内部。四个后端(第四个是继承 `SqlDriver` 的
+  `driver-sqlite-wasm`)现在给出同一个 `INVALID_FILTER` / 400,消息里指名出事的位置
+  (如 `filter.$or[0].stage`)。
+
+  **⚠️ 可观察的行为变更 —— RLS `check` 求值路径。** `@objectstack/formula` 的
+  `matchesFilterCondition` 是 `plugin-security` 对 insert/update **后像**执行行级 `check`
+  的那条路径(没有查询可下推,这个求值器就是执行本身)。它改为抛出后,落在 #4775
+  「求不出值 = 该次操作失败」的既定姿态上。这不只是「拒绝得更响」——有一类结果直接翻转:
+
+  | `check` 策略                                    | 改前                                  | 改后                     |
+  | ----------------------------------------------- | ------------------------------------- | ------------------------ |
+  | `{ a: {} }`                                     | FALSE → 写入被拒(403)                 | 抛出 → 该次写入失败(400) |
+  | `{ $or: [ { a: {} }, { owner: '{userId}' } ] }` | FALSE 被另一析取项吸收 → 写入**放行** | 抛出 → 该次写入失败      |
+  | `{ $not: { a: {} } }`                           | `!false` → 写入**放行**               | 抛出 → 该次写入失败      |
+
+  后两行是**原本能成功、现在会失败**的写入。这是拍板的目的而非副作用:一条含
+  `{ field: {} }` 的权限规则,是一条作者弄丢了操作符的规则,它的含义不该取决于四个后端里
+  哪一个在求值。升级后请检查 `check`/`using` 策略里是否存在零操作符的字段约束——
+  错误消息会指名位置。
+
+  同一条改动也让 `@objectstack/driver-memory` 的两个过滤面(经 mingo 的实时查询路径,
+  与跨后端一致性套件所用的 `memory-matcher` 参考匹配器)第一次对这个形状给出同一个答案。
+
+  非空形状**逐字符不变**:普通比较、`$in`、`$or`/`$and` 组合、`$not` 的 #5146 NULL-safe 改写,
+  编译出的 SQL 文本与匹配结果都与改前相同;`{}`(零个键的**节点**,#5134 的布尔单位元)
+  与 `{ field: {} }` 是两个不同形状,前者的语义不受本次影响。
+
+  注:本次收紧的是**实现**。`packages/spec` 的 `FilterConditionSchema` 仍然声明这个形状合法
+  (非递归半边是 `z.record(z.string(), z.unknown())`),即实现现在比已声明的契约更严;
+  契约收窄与 `FILTER_LOGIC_CASES` 补条归 spec 车道另行处理。
+
+- 58f3220: 新增规范 parse-to-AST 入口 `parseCelToAst(source)`,并 re-export AST 节点类型 `CelAstNode`(#4812)。
+
+  `parseCelToAst` 与 `compile` / `evaluate` / `collectCelRootIdentifiers` 共用同一条前端链路
+  ——#3306 的 `rewriteNullableTernary` 重写、`DEFAULT_LIMITS` 边界、以及注册了 stdlib 的
+  `unlistedVariablesAreDyn: true` 环境 —— 因此全仓对「什么能解析」只有一个答案。此前消费方
+  若自建 `new Environment(...)`,拿到的是一份**不带 limits** 的答案:它会解析、并进而推理
+  `compile()` 直接拒绝的表达式。
+
+  `parseCelToAst` 只做 parse,不做 check(后者是 `compile()` 的职责):解析成功但类型检查失败的
+  表达式(大量 `dyn` 操作数的谓词即是)仍然会拿到 AST。解析失败返回 `null` 而不抛错。
+
+  `CelAstNode` 的 re-export 补上了一个既有缺口:`lowerCelAst` 一直接收 cel-js 的 `ASTNode`,
+  而该类型从未导出,消费方只能越过本包直接依赖 `@marcbachmann/cel-js` —— 这正是第二个解析入口
+  的成因。
+
+- bf1edef: feat(formula,lint): wire ADR-0056 D4's RLS authoring gate, from the runtime's own predicate (#4983)
+
+  `isSupportedRlsExpression` has carried the same docblock since ADR-0056 D4:
+  "exposed so an authoring-time gate (`objectstack compile`) can REJECT a
+  predicate the runtime would silently drop … A `false` here means 'this
+  predicate will never enforce'." It had **no non-test consumer anywhere** — the
+  function written to fix declared-but-never-read was itself declared and never
+  read. This lands the consumer, in two steps that had to happen in this order.
+
+  **1. `sqlPredicateToCel` and `isSupportedRlsExpression` move FROM
+  `@objectstack/plugin-security` (`src/rls-compiler.ts`) TO `@objectstack/formula`
+  (`src/rls-predicate.ts`), and are exported from its root.** Executable code
+  unchanged — a change of address, not of behaviour; `plugin-security` now imports
+  them from `@objectstack/formula` and keeps no copy, so there is still exactly
+  one definition. No import path outside the two packages changes: neither symbol
+  was ever exported from `@objectstack/plugin-security`'s entry point. The move is
+  what makes step 2 possible at all — `@objectstack/lint` may depend on
+  `@objectstack/spec` and never on a runtime, so with the predicate living in a
+  runtime the gate's only other door was copying the SQL→CEL bridge, whose
+  boundary conditions (quoted literals are never rewritten; canonical CEL passes
+  through unchanged) _are_ the gate's red/green line. A fork drifting by one
+  character rejects policies the runtime executes correctly — the false-positive
+  direction, which is worse than the gap. ADR-0058 D1 asks for a single canonical
+  shape gate; the bridge is part of that gate.
+
+  **2. New `@objectstack/lint` rule `validateRlsPredicateEnforceability`,
+  `error`, on all three authoring commands**, over
+  `permissions[].rowLevelSecurity[].using` and `.check`:
+
+  - **`rls-predicate-unenforceable`** — parses as CEL, outside the pushdown
+    subset: a function call (`size(...)`, `has(...)`), arithmetic, a ternary, a
+    cross-object path (`record.account.region`).
+  - **`rls-predicate-unparseable`** — does not parse as CEL even after the legacy
+    SQL bridge (`=` → `==`, `IN` → `in`): SQL `AND` / `OR` / `LIKE`, a subquery.
+    Its own id because the fix is different — write CEL (`&&`, `||`), not a
+    different shape.
+
+  What the gate prevents, measured through `plugin-security` rather than inferred:
+  `RLSCompiler` drops the policy and logs one request-time WARN. On the read path,
+  when it is the only applicable policy, `compileFilter` returns the
+  `RLS_DENY_FILTER` sentinel instead, which is AND-ed onto the where clause — so
+  every select / update / delete on the object matches **zero rows**. On the
+  ADR-0058 D4 write path the post-image `check` becomes that same sentinel, which
+  no record satisfies, so every insert / update fails with `PermissionDeniedError`.
+  The runtime fails closed, which is why this was survivable: the result is not a
+  hole but a policy that reads as an authorization and behaves as a blanket
+  refusal, with nothing at authoring time pointing at the line that caused it.
+
+  Fix a flagged predicate by rewriting it inside the lowerable subset — `==` `!=`
+  `>` `<` `>=` `<=`, `in`, `&&` `||` `!`, `== null` / `!= null`, and
+  `startsWith` / `endsWith` / `contains` over single-column field paths (ADR-0058
+  D2), against a literal or a `current_user.*` value. Two specific migrations:
+  `has(x)` / `size(x) > 0` → `x != null` (a function call is correct in an object
+  _validation_ rule, which is interpreted, and wrong here, where the predicate is
+  compiled to a filter); and a related record's field → denormalise it onto this
+  object (formula/rollup) and test that column, since RLS cannot join (ADR-0055).
+
+  Same construction as the sharing-rule gate (#4698): the rule does not model the
+  consumer or grep for it — it calls `isSupportedRlsExpression`, the exact
+  function `RLSCompiler.compileFilter` consults to decide whether a dropped policy
+  earns its warning, so the two verdicts are one boolean by construction, pinned
+  in both directions over a shared corpus. Measured before shipping: every RLS
+  predicate declared anywhere in this repo — the `plugin-security` platform seeds,
+  the examples, the dogfood fixtures, the authoring skill — is supported, so the
+  gate turns nothing red that works today. Unlike the sharing-rule gate, CEL
+  _syntax_ is reported here rather than deferred to `expression-invalid`:
+  `validateStackExpressions` does not walk `rowLevelSecurity` at all, and could not
+  judge this field correctly if it did, because `owner_id = current_user.id` is a
+  CEL syntax error and a working RLS predicate at the same time.
+
+### Patch Changes
+
+- 07f1822: fix(formula): `matchesFilterCondition` 的 `$exists` 改读「有值」,与 `$null` 成严格互补
+
+  **行为变更,影响 RLS 写侧 `check` 的判定。** `{ x: { $exists: true } }` 对
+  `{ x: null }` 以前答 `true`(键存在),现在答 `false`(没有值)。
+
+  `matchesFilterCondition` 是 RLS `check` 子句(insert/update 的 post-image)的求值器 ——
+  写路径上没有查询可以下推,只能逐记录判定。它此前把 `$exists` 读成「键是否存在」
+  (`actual !== undefined`),而 `driver-sql` 一直把同一个算子编译成 `IS NOT NULL`。
+  于是同一条规则里的 `$exists`,写侧放行的记录读侧看不见。
+
+  2026-08-06 裁定取「有值」,理由是另一种读法在最要紧的地方**无法兑现**:SQL 里列
+  **就是** schema,一行不可能「缺一个键」,所以 `driver-sql` 除了 `IS NOT NULL` 别无
+  可编译的东西。字段的存在性是 **schema** 的属性,不是**记录**的属性;spec 若声明
+  「键是否存在」,就是在承诺两个后端永远交付不了的语义。因此 `driver-sql` 的发射器
+  一字未动,移动的是本求值器。
+
+  对齐之后 `$exists` 与 `$null` 在每个后端上都是严格互补:
+  `$exists: true` ≡ `$null: false`,`$exists: false` ≡ `$null: true`。
+  「键缺失」与「值为 null」在这里是同一个事实 —— 这也正是 `getPath` 对两者本来就
+  返回同一个 `undefined` 的原因。
+
+  `$ne` / `$nin` / `$notContains` / `$null` 四个算子本来就是本次裁定的目标语义,
+  一字未改。
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [d9971d3]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Patch Changes
diff --git a/packages/formula/package.json b/packages/formula/package.json
index 98f668214d..fafbd408bc 100644
--- a/packages/formula/package.json
+++ b/packages/formula/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/formula",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "ObjectStack canonical expression engine — CEL (cel-js) + ObjectStack stdlib + dialect registry",
   "main": "dist/index.js",
diff --git a/packages/lint/CHANGELOG.md b/packages/lint/CHANGELOG.md
index 491b392b3a..81cdb8c11d 100644
--- a/packages/lint/CHANGELOG.md
+++ b/packages/lint/CHANGELOG.md
@@ -1,5 +1,1934 @@
 # @objectstack/lint
 
+## 17.0.0-rc.4
+
+### Minor Changes
+
+- 28ad90e: feat(types,cloud-connection,lint,cli): ADR-0120 17.x 收尾 —— `isolated` 安装期姿态硬门(D5e)、D5c 重拼写 advisory、成文契约扫荡与三姿态 conformance (#5081)
+
+  ADR-0120 17.x 波的第三块,也是最后一块。前两块已在 main 上:#5212(driver 侧
+  D3+D4 —— `COALESCE(organization_id, '__global__')` 物化、drift 两侧同步、重复预检)
+  与 #5208(spec 词汇 `'organization'` + D5a/D5b lint)。本次补齐三件事:安装期的
+  姿态决策点、剩余的成文契约、以及把「一个 app 包跑遍三种姿态」从假设变成测试。
+
+  **D5e —— 装进 `isolated` 环境时的硬门。** 词汇本身是姿态无关的:作者说的是业务
+  边界(`'organization'` 一个组织一份 / `'global'` 整个安装一份),没有任何索引形状
+  读姿态。唯一的残留在一个方向上:`isolated` 下组织就是**不同客户**,此时 app 业务
+  对象上的 `'global'` 唯一既跨客户过度约束,又变成跨客户的存在性预言机(S10/S14)。
+  维护者裁定这是**硬门而非 advisory**:把带 `'global'` 唯一(非 `sys` 对象)的 app
+  装进 `isolated` 环境会**停下来并逐索引列出**,安装者(通常是 AI agent)要么确认它
+  确实是平台级的,要么改写为 `'organization'`;确认按 ADR-0104 attestation 风格
+  留痕在安装清单里(`InstalledManifestEntry.globalUniqueAttestation` —— 确认了什么、
+  谁确认的、何时、在哪个姿态下问的),**之后不复问**。
+
+  - 停下的安装**什么都不留**:先于 hot-register 和任何 ledger 写入,所以作者改完
+    元数据可以直接重试,不需要先卸载。
+  - 逐索引确认是有牙齿的:`confirmGlobalUniques` 收 `true` 或明确的 id 数组,只确认
+    其中一条仍会在剩下的那条上停住。
+  - 升级引入的**新**约束会被问,老的答案继续算数。
+  - 另一个姿态下给出的确认**不算同意** —— `isolated` 那个问题在 `single` 下从未被
+    问过,所以按「未确认」处理(唯一不会静默放行跨客户约束的方向)。
+  - ⛔ **永不做成启动期告警**(#4884 纪律)。boot 时的 rehydrate 不评估此门;门够不到
+    的两类存量 —— 门禁上线前的安装、装后姿态变更的环境 —— 由 `os doctor` 与
+    `os migrate plan` 的 advisory 形态覆盖。
+
+  判定里有三条是承重的,别「简化」掉:声明索引上的裸 `unique: true` **算**(D1 说它
+  就是 `'global'` 的位置式拼写,排除它等于让整个 17.x 可以靠拼写绕过);字段级
+  `true` **不算**(它是 `'organization'`,永久合法);`sys_`/`base_` 对象**不算**
+  (S5 那批引擎幂等键天然就是平台级的,每次安装都问一遍就是 #4884 的误报类)。
+
+  CLI: `os package install` 新增 `--confirm-global-uniques`,并把 409 渲染成可读的
+  逐条清单而不是一句 "Install failed (409)"。
+
+  **D5c —— 遗留手写组织复合索引的 advisory。** 新规则
+  `unique/legacy-organization-composite`:声明的唯一索引自己列出了组织列
+  (`{ fields: ['name','organization_id'], unique: true }`)—— 这是词汇出现之前手写
+  per-organization 的写法。它读起来像「每组织唯一」,物化出来却是普通复合索引,而
+  SQL UNIQUE 是 NULL-distinct 的:组织列为 NULL 的行上它**什么都不约束**(#5030),
+  在单组织部署上那就是每一行。改写成 `unique: 'organization'`(`fields` 原样保留,
+  driver 会把已列出的组织列**就地**变成 NULL-safe 形式)正是补上这个洞的动作。
+  **永远只是 advisory,永远不自动修**:老拼写永久合法、零强制 drift,而 opt-in 是
+  真实的物理收紧,要走 D4 的 `recreate_index` + 重复预检。
+
+  **D6 —— 成文契约扫荡。** `content/docs/data-modeling/indexing.mdx` 的
+  §Two ways to say "unique" 全节按新词汇重写(含 `os:check` 代码块);
+  `content/docs/protocol/objectql/schema.mdx` 的 §Uniqueness and tenancy 重写为
+  §Uniqueness and scope —— 其中那句「单租户部署不受影响,租户列是常量,复合索引
+  退化为单列索引」是 #5030 **证伪过的原话**,现已替换为 D3 的 NULL-safe 事实;
+  `content/docs/deployment/cli.mdx` 的 `replace_unique_index` / `recreate_index`
+  条目补上 NULL-safe 形状与重复预检;`content/docs/references/**` 经
+  `gen:schema && gen:docs` 再生成,未手改。
+
+  按 ADR-0120 Resolved #2 的非规范性引导(官方示例/脚手架/生成器在新代码中输出
+  显式拼写),`skills/objectstack-data/**` 的索引与校验规则整体扫过:声明索引一律
+  说清 scope,并新增一节完整讲 `'organization'` 的 NULL-safe 语义与「永远不写姿态」。
+  顺带修掉那里长期使用的 `tenant_id` —— 平台的列叫 `organization_id`。
+  `examples/**`、`create-objectstack` 模板与 `os generate` 经核查**根本没有声明任何
+  唯一约束**,故无可扫;这是核查结论,不是遗漏。
+
+  **三姿态 conformance(ADR §Acceptance tests)。** 同一个 fixture app 在
+  `single | group | isolated` 三姿态下启动,逐 S 行用**真实的违规插入**断言 enforcement
+  (S1/S2/S3/S4/S5/S6/S7/S8/S9/S11/S12),并逐姿态捕获物化出的索引键,断言三者
+  **逐字节相同** —— 「没有任何索引形状读姿态」这句话一旦有两者不同就是假的。相同性
+  断言配了一条正向断言(对着期望的键形状),这样「三次都什么都没建」不会读成「一致」。
+  外加 ADR 只要的那一条 transition smoke:在 `single` 下建库、`isolated` 下重新打开,
+  drift op 为零。
+
+  对既有部署的影响:除新增的安装期确认外,本次不改变任何已有物化行为。字段级
+  `unique: true` 一如既往合法。
+
+- ddc2527: fix(approvals): the ADR-0044 revise window is a service-owned node type, not a bare `wait` (#3823)
+
+  #3801 gated `POST /api/v1/automation/:name/runs/:runId/resume` on the **node type**
+  that produced the suspension: an `approval` pause declares
+  `resumeAuthority: 'service'`, so it continues only through `ApprovalService`.
+  ADR-0044's **revise window** was the same trust boundary in a shape that key
+  could not see. Send-back parked the run on an ordinary `wait` node the flow
+  author placed — correctly `resumeAuthority: 'any'`, because a signal wait is
+  _meant_ to be resumable by an external producer — and `ApprovalService.resubmit`
+  was the only thing that checked anything about continuing it.
+
+  Demonstrated (not reasoned) against the real engine: a raw `resume(runId)` with
+  an **empty body**, from any caller, walked the `resubmit` back-edge into the
+  approval node and opened round N+1 with **no submitter check and no `resubmit`
+  audit row** (`['submit','revise']` — no third row, ever). Worse, when another
+  request was already pending on the record — the exact case `resubmit` refuses
+  with `DUPLICATE_REQUEST` _specifically to keep the run alive_ — the raw resume
+  went around that guard: the approval node's re-entry failed **after** the engine
+  consumed the suspension, and the run was **permanently destroyed** with its
+  round-N request stuck `returned` and no resubmit able to reach it.
+
+  The revise pause is therefore its own node type:
+
+  - **`approval_revise`** (`APPROVAL_REVISE_NODE_TYPE`), registered by
+    `@objectstack/plugin-approvals` alongside the `approval` node, declaring
+    `resumeAuthority: 'service'`. It stays a first-class box on the canvas, in the
+    run log and in the suspended-run store — only the _reuse_ of `wait` was wrong.
+    It takes **no config**: the window ends on the submitter's explicit resubmit,
+    never on a signal or timer. The `resumeAuthority` gate itself is unchanged.
+  - `sendBack` refuses a `revise` edge whose target is not an `approval_revise`
+    node, **before any mutation** (like the existing missing-`revise`-edge check),
+    so no run can be parked in a window something else can advance.
+  - New gating lint `flow-approval-revise-target-not-service-owned`
+    (severity `error`, on `os build` / `os validate` / `os lint` and the runtime
+    metadata publish gate) rejects the old shape at authoring time.
+
+  **Upgrading a flow authored against the original ADR-0044 D3.** One token:
+
+  - **FROM:** `{ id: 'wait_revision', type: 'wait', waitEventConfig: { eventType: 'signal', … } }`
+  - **TO:** `{ id: 'wait_revision', type: 'approval_revise' }` — drop
+    `waitEventConfig` / any `config`; the window has no event to wait on.
+
+  Until you do, such a flow keeps registering and running and its approvals stay
+  decidable (`approve` / `reject` / `recall` / `reassign` are untouched), but
+  **send-back is refused** with a message naming the node and this fix, and
+  re-publishing it reports the lint error. A run _already parked_ in a legacy
+  revise window keeps its recorded node type (a republish never re-types a live
+  pause) and is drained by `resubmit` or `recall` as usual.
+
+  ADR-0044's 2026-07-28 amendment records the reversal of its D3 and of its
+  `Alternatives` rejection of a service-owned revise pause, with the evidence
+  above; the implementation section there records what shipped, why the approval
+  node does not re-suspend itself instead, and why no ADR-0087 conversion was
+  added for the old shape.
+
+- 0161c7f: feat(spec,lint): declare the chart segment drill — `ChartDrillDownSchema`, on the react tier where it is actually read (#5022)
+
+  `drillDown` has driven a real capability since long before this release: click a
+  bar or a slice on an `<ObjectChart>` and objectui opens the underlying records,
+  filtered by the clicked category, in a drawer. The protocol declared it
+  **nowhere**. objectui read it as `(schema as any).drillDown`, so every key inside
+  it — right, wrong, or misspelled — reached the renderer unchecked, and a typo was
+  simply ignored at click time. This is Prime Directive #10 inverted: not declared
+  without being delivered, but delivered without ever being declared.
+
+  It is declared now, as `ChartDrillDownSchema`, and it is **additive** — nothing
+  that parsed before stops parsing.
+
+  ## What you can write
+
+  `drillDown` is a prop on the react-tier `<ObjectChart>` block:
+
+  ```jsx
+  <ObjectChart
+    objectName="opportunity"
+    aggregate={{ function: "sum", field: "amount", groupBy: "stage" }}
+    drillDown={{ columns: ["name", "amount"], maxRows: 50 }}
+  />
+  ```
+
+  | key       | type                      | meaning                                                                                                                                            |
+  | --------- | ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
+  | `enabled` | `boolean`                 | Only needed to force the drill OFF — the block being present already means on, so `drillDown={{}}` enables it                                      |
+  | `filter`  | `Record<string, unknown>` | Filter for the drilled list; values support `${event.*}`. Omit it and the filter is derived from `aggregate.groupBy` equal to the clicked category |
+  | `title`   | `string`                  | Drawer/dialog heading; supports `${event.*}`                                                                                                       |
+  | `target`  | `'drawer' \| 'dialog'`    | In-place side sheet (default), or a centered modal when the chart is already inside a drawer                                                       |
+  | `columns` | `string[]`                | Column whitelist for the drilled list                                                                                                              |
+  | `maxRows` | `number`                  | Rows per page in the drilled list                                                                                                                  |
+
+  Every one of those six is a key objectui's `ObjectChart` was measured to read.
+  The renderer's own drill type is wider — it is shared with the table / pivot /
+  metric widgets — and the extra keys are **deliberately not declared**, because a
+  chart reads none of them:
+
+  - **`mode`** (`'filter'`/`'record'`) is a table/pivot/metric key. A chart segment
+    is always an aggregate, so there is nothing to discriminate.
+  - **`report`** (drill into a report instead of a record list) is a metric/pivot
+    capability.
+  - **`view`** and **`sort`** are read by _no_ renderer at all (objectui#3354).
+  - **`target: 'navigate'`** is implemented for the other widgets but not for a
+    chart, which falls back to the drawer.
+
+  Writing any of them is now a loud rejection that says which surface owns it,
+  rather than a value that silently does nothing.
+
+  ## Where it is NOT declared, and why that is deliberate
+
+  **Not on `ChartConfigSchema`, and not a dashboard widget key.** A dashboard
+  widget has no per-widget drill configuration, by design: an ADR-0021
+  dataset-bound widget drills through the semantic layer, deriving the target
+  object and filter from the dataset row that was clicked. That is what
+  `content/docs/ui/dashboards.mdx` has said all along, and it is what the renderer
+  does — `DashboardRenderer` never reads `chartConfig`, and `DatasetWidget`
+  forwards exactly one key out of it (`showLegend`). Declaring the drill there
+  would have produced authorable metadata that parses clean and never reaches a
+  renderer — the failure this campaign removes elsewhere.
+
+  So the three places an author might reach for it now answer instead of shrugging:
+
+  - `widget.chartConfig.drillDown` → rejected, pointing at the react-tier prop.
+  - `widget.drillDown` / `widget.drilldown` → rejected, explaining that dashboard
+    drill-through is **automatic**, and naming both configurable drills.
+  - `report.drillDown` → rejected, pointing back at the chart prop.
+
+  ## `drillDown` is not `drilldown`
+
+  Two capabilities, one letter apart, and they are now disambiguated in both
+  directions at the schema gate:
+
+  |          | `drillDown`                | `drilldown`                                     |
+  | -------- | -------------------------- | ----------------------------------------------- |
+  | spelling | camelCase                  | all lowercase                                   |
+  | type     | configuration object       | boolean                                         |
+  | surface  | react `<ObjectChart>` prop | `ReportSchema` key (ADR-0021 D2, on by default) |
+
+  Edit distance alone gets this wrong — the two spellings are a distance of 1, so a
+  plain "did you mean" would happily send an author writing `drillDown` on a report
+  to `drilldown`, where their config object then fails a second time as a boolean.
+  Both gates name the **type** difference, not just the spelling.
+
+  ## Enforced, not just declared
+
+  `@objectstack/lint`'s react-page publish gate now **parses** the schema
+  (`react-chart-drilldown-invalid`) against a static `drillDown={{…}}` literal,
+  rather than re-deriving the rules. Unknown keys, the wrong `target`, and the
+  near-key spelling all fail the build with the schema's own prescription. A value
+  assembled from React state is skipped, unchanged: an unresolvable binding is not
+  a wrong one (ADR-0072 D1).
+
+- eaaf03c: refactor(spec,lint)!: retire the dashboard widget action trio + `aria` — and the build gate that enforced a button nobody renders (#5010, ADR-0049)
+
+  `DashboardWidgetSchema` let an author declare a per-widget action **button**
+  (`actionUrl` / `actionType` / `actionIcon`) and per-widget ARIA attributes
+  (`aria`). None of the four reached a renderer. Re-measured 2026-08-04 across both
+  repos on a closed call graph:
+
+  - **the action trio** — all 14 `actionUrl` reads in objectui's
+    `DashboardRenderer.tsx` are scoped to `schema.header.actions[]`, which is
+    `DashboardHeaderAction`, a _different_ schema. Nothing anywhere reads
+    `widget.actionUrl`. `actionIcon` is the starkest: zero references in either
+    repo outside its own declaration — not even the lint looked at it.
+  - **`aria`** — no consumer of `widget.aria` anywhere. The `aria-*` attributes in
+    `DashboardRenderer` / `DatasetWidget` are the renderer's own DOM attributes,
+    and objectui's single `.aria` read (`plugin-view/ObjectView.tsx:989`) is a
+    **view**'s. This is the dashboard-level `aria` that #3896 removed, one level
+    down — an accessibility guarantee an author could declare and nothing honoured.
+
+  These four survived the #3896 sweep for the same reason `widgets[].responsive`
+  did, and it is not "we looked and they were live": the liveness ledger declared
+  no `children` on `dashboard.widgets`, so **no widget-level key had ever been
+  classified**. #4956 fixed that instrument and gave all 22 keys their first per-key
+  verdicts; this change acts on four of the six it found dead.
+
+  ## The second-order cost this settles
+
+  `packages/lint`'s `validate-dashboard-action-refs` enforced **ERROR-severity**
+  reference integrity on `widgets[].actionUrl` — a dangling target failed the
+  build. Its docblock called the key _"the per-widget button"_ and claimed to
+  mirror the objectui runtime dispatch. It did not, because that button does not
+  exist. So an author could be blocked from shipping because a control that cannot
+  render pointed at an action that also did not.
+
+  A rule written to delete false affordances was sustaining one. That is why the
+  keys were retired rather than the check merely relaxed: the widget branch is
+  deleted, with a pin test asserting it stays silent and a second pin proving
+  header actions are still checked in the same stack.
+
+  FROM → TO:
+
+  | Removed                          | Replacement                                                                                            |
+  | :------------------------------- | :----------------------------------------------------------------------------------------------------- |
+  | `dashboard.widgets[].actionUrl`  | `dashboard.header.actions[].actionUrl`                                                                 |
+  | `dashboard.widgets[].actionType` | `dashboard.header.actions[].actionType`                                                                |
+  | `dashboard.widgets[].actionIcon` | `dashboard.header.actions[].icon` (the header spelling)                                                |
+  | `dashboard.widgets[].aria`       | **none** — delete it; author `title`/`description`, which the renderer really does label the card with |
+
+  For a per-**row** affordance, reach for a dataset-bound `table`/`pivot` widget:
+  its rows are clickable and drill through the semantic layer already (no
+  per-widget drill config exists, by design — #5022).
+
+  **The `AriaProps` shape is NOT removed — only this embed.** `AriaPropsSchema` /
+  `AriaProps` stay exported and stay live on `app.aria` and
+  `page.components[].aria`. Nothing importing the shape breaks.
+
+  The retirement kit:
+
+  - **Tombstones.** `retiredKey()` on all four, matching `responsive` in this same
+    schema. `DashboardWidgetSchema` _is_ `.strict()`, so a plain delete would still
+    be loud — but only as a generic "unrecognized key". The tombstone keeps the key
+    declared so the rejection carries the **prescription**, and types it `never` so
+    authoring it fails `tsc` first. Pins assert the message _is_ the prescription
+    and is _not_ `Unrecognized key`. The action trio shares one prescription that
+    names all three, so an author who deletes the one key they were told about does
+    not hit the same error twice more.
+  - **ADR-0087 D2 conversion + D3 chain step**
+    (`dashboard-widget-action-aria-removed`, `retiredFromLoadPath`):
+    `os migrate meta --from 16` strips the four from author sources, and stored
+    dashboards replay clean instead of meeting a tombstone at load. Lossless
+    deletes — none of the keys had an effect to lose. Its own entry rather than
+    more keys on `dashboard-inert-keys-removed`, whose identity is the #3896 sweep.
+  - **Liveness rows stay** (`status: dead`, `verifiedAt`, a REMOVED note) because
+    a tombstone keeps the key in the walked shape — the `rls.priority` precedent.
+    `authorWarn`/`authorHint` are dropped from all four: the parse owns them now.
+  - Baselines moved at KEY level only, as the shape's survival implies:
+    `authorable-surface.json` gains four `… [RETIRED]` lines;
+    `json-schema.manifest.json`, `api-surface.json` and
+    `api-surface-signatures.json` are unchanged by construction — no def stopped
+    being emitted and no export was removed.
+
+  No runtime behaviour changes — that impossibility is the reason for the removal.
+  The one behaviour that _does_ change is a build that used to fail and now does
+  not.
+
+  ## Not in this change
+
+  `widgets[].colorVariant`, the fifth dead key #5010 lists, is **deliberately
+  untouched**. The rewrite target its triage assumed — `options.colorVariant` —
+  measured dead as well: `options` only reaches a renderer through the inline
+  `componentSchema` path, and `dataset` is _required_ on this schema, so every
+  spec-authorable widget is dataset-bound and renders through `DatasetWidget`,
+  which has no colour affordance at all. Moving the key would relocate 16 authored
+  sites (7 in `platform-objects`, 9 in `app-showcase`) from one dead slot to
+  another and mint a second inert key. Returned for adjudication.
+
+- 06ffad3: fix(lint): 字段公式校验首次对 spec 合法元数据生效 —— `f.formula` 收敛为 `f.expression` (#5026)
+
+  `validate-expressions.ts` 的字段公式校验(`validateStackExpressions` 里的
+  field-formula pass)一直读 `f.formula`。`FieldSchema` 声明的是 `expression`,而
+  `formula` 恰是 `field.zod.ts:333` **按名拒绝**的别名之一
+  (`aliases: { formula: 'expression', calculation: 'expression', compute: 'expression' }`)。
+  该规则以 `input: 'parsed'` 注册,compile/build/validate 路径上看到的是
+  `ObjectStackSchema` 的解析产物,所以 `f.formula` 恒为 `undefined` ——
+  **整段检查对任何 spec 合法 stack 从未执行过一次**。
+
+  这不是删死代码,是**启用一条从未跑过的检查**。字段公式从此真正受
+  ADR-0032 §1a/1b 的三条判决管辖:CEL 语法、`record.<field>` 字段存在性、
+  以及 #1928 的裸引用 / 类型健全性。对 AI 生成的元数据这一条最要紧 ——
+  `amount * probability`(而不是 `record.amount * record.probability`)正是公式槽位
+  最常见的错法,它在 CEL 里静默求值为 null,过去没有任何门拦得住。
+
+  **覆盖面扩大,但对现有元数据零新红。** 激活后在仓库全部真实元数据上实测过:
+  `examples/app-showcase`(3 个 `expression` 槽)、`examples/app-crm`(5 个)、
+  `examples/app-todo`(0 个)全部 `ObjectStackSchema` 解析通过,新增判决 0 条;
+  `platform-objects`、`plugin-security` 的 default-permission-sets 不含公式字段;
+  `skills/` 里的公式样例全部已是 canonical 拼法。
+
+  **Authoring impact.** 之前拼 `formula:` 的字段本来就无法解析,schema 会按名拒绝
+  并给出 `Did you mean \`formula\` → \`expression\`?`——该行为不变,本规则不再对同一个键
+  给出第二套说法。诊断定位串同步改名以免继续传播错拼法:
+
+  ```
+  FROM  object 'X' · field 'Y' formula
+  TO    object 'X' · field 'Y' expression
+  ```
+
+  `validate-null-guards.ts` 的 surface ledger 相应把该行从 `Field.formula` 正名为
+  field `expression`(`Field.formula({ expression: … })` 写入的槽)。null-guard 判决
+  **仍然**排除该 surface(公式是 `value` 角色、天然可空,`guard ? value : null` 是祝福
+  写法),排除的只是 null-guard 这一条,语法 / 字段存在性 / 裸引用判决从此生效。
+
+  `validate-expressions.test.ts` 的 `TRACKED_UNDECLARED_READS` 记账随之清空 —— 这
+  份"只缩不长"的清单现在是零条,规则读的每一个键都是 spec 声明的键。
+
+- 123067c: fix(cli): the i18n walker collects `objects.<o>._sections` — section headings are gated and scaffolded like every other label (#5405)
+
+  An object's SECTION headings were the one declared, resolved, rendered
+  translation surface the shared i18n walker had no kind for.
+  `ExpectedEntry['source']` listed `object | field | option | view | action |
+globalAction | app | navigation | dashboard | widget | page` plus two
+  `metadataForm*` kinds — and those two cover **Studio metadata forms**
+  (`metadataForms.<type>.sections.*`, hidden behind `--include-platform`), not app
+  objects. So `objects.<o>._sections.<s>.label` was structurally unreachable in
+  both directions: `os i18n extract` never scaffolded a heading, and
+  `os lint` could not report one missing.
+
+  The surface itself was never in doubt. `ObjectTranslationDataSchema` declares
+  `_sections` (with `sections` as an authoring alias), and `@object-ui/i18n`'s
+  `sectionLabel` resolves it for `record:details`, for `ObjectForm`/`ModalForm`
+  and for the field-group designer. Only the walker disagreed — which is exactly
+  the drift `collectExpectedEntries` was consolidated to prevent (#3370).
+
+  Measured downstream before this landed: 85 sections across 15 objects, **2 of
+  85** translated in `ja-JP` and in `es-ES` — English headings on essentially
+  every record page and form — with `objectstack lint` reporting **zero** i18n
+  warnings for both locales.
+
+  **What is collected.** A `section` kind, from the two independent surfaces that
+  both resolve to the same key — a heading is expected if _either_ declares it,
+  and one heading is one expected key however many declare it:
+
+  - **`fieldGroups` × field `group`** — the fields decide which sections exist and
+    `fieldGroups[].label` supplies the source text. Membership is read through
+    `deriveFieldGroupLayout` (ADR-0085 §5), the same shared derivation the
+    renderers consume, so a group nothing visible references — or a `group:` no
+    `fieldGroups` entry declares — produces no heading and therefore no expected
+    key. The trailing ungrouped bucket renders without chrome and is skipped.
+  - **A named `sections[]`** on a form view (including a view container's default
+    `form`) or inside a record page's component tree.
+
+  A section with no `name` is skipped: every renderer guards the lookup on it
+  (`s?.name ? sectionLabel(…) : s?.label`), so it is untranslatable by
+  construction and demanding a bundle entry for it would be noise. A group that
+  declares no `label` still yields a scaffold key seeded from its own name, but no
+  coverage finding — nobody authored that text.
+
+  **What you get.** `os lint` gains an `i18n/missing-section` category — user
+  metadata, so it is reported without `--include-platform` — and `os i18n
+extract` scaffolds the headings for free, because the gate and the extractor
+  read the one walker. A project that declares no locales still reports nothing;
+  the gate stays opt-in.
+
+  **`@objectstack/lint`** now exports its shared page traversal
+  (`walkPageComponents`, `isSourceAuthoredPage`, `WalkedComponent`) so the CLI
+  consumes it instead of growing a private copy — that walk exists precisely
+  because duplicating it produced a dead rule once already (#3583). Reusing it is
+  also what makes the page half correct rather than merely present: it reaches
+  `slots.<slot>` and the untyped nesting a record page really uses
+  (`page:tabs` → `properties.items[].children[]` → `record:details`), skips
+  source-authored pages whose `regions` are a derived cache, and resolves each
+  component's OWN binding (`dataSource.object` → `properties.object` → the page's
+  `object`) — so a re-bound `record:details` keys its headings under the object it
+  actually shows.
+
+- 5582e18: never-fire 族三条 lint 规则 warning → error:声明了触发器却确定不会运行的 flow 现在被拒收
+
+  `validateFlowTriggerReadiness` 里的规则此前一律是 warning。族内复审(#5762)后按**一个**标准重新定级 ——
+  「仅凭这份 stack 是否已经足够断定这个 flow 不会运行」—— 三条规则答「是」,升为 `error`:
+
+  - **`flow-time-relative-descriptor-invalid`**(#5496)—— `config.timeRelative` 描述符
+    `TimeRelativeTriggerSchema` 判不过。判它的正是 trigger 在 bind 时 `safeParse` 的同一个 schema,
+    所以 schema 拒的描述符在运行时同样被拒:sweep 永不安装,flow 声明了 time-relative 触发器却永不运行。
+  - **`flow-time-relative-descriptor-unroutable`**(#5647)—— `config.timeRelative` 不是对象
+    (`timeRelative: 'daily'` 是典型)。判据就是引擎自己的路由谓词 `typeof … === 'object'`,
+    所以这个值不会被任何部署路由到 time-relative trigger —— 全族里最硬的判定,也是唯一连
+    bind 时那一行 warn 都没有的一条。
+  - **`flow-trigger-unknown-event`**(#3427/#3457/#3481)—— `record-*` token 落在文法之外
+    (`record-after-updated` 拼错、`record-change` 缺相位、数组形式)。引擎用硬编码前缀把任何
+    `record-` 开头的 token 路由给 record-change trigger(不查注册表,所以装任何包都无法声明新
+    `record-*` token),该 trigger 再用 `triggerTypeToHookEvents` 的封闭文法映射 —— 文法外就是零
+    hook event,即绑不上任何东西。
+
+  **两条对照规则维持 warning,这正是本次定级不是「整个文件都升 error」的原因:**
+
+  - `flow-trigger-unknown-object` —— 本 stack 没定义的对象名**可能由另一个已安装包提供**,
+    规则看不见那个包的对象。免责是真的,所以继续 advisory(它自己的 hint 就这么写)。
+  - `flow-draft-status-ambiguous` —— draft flow **确实会**触发,这是意图歧义而非死 flow。
+
+  ## 影响面:P1 运行时发布门(`surfaces: CLI_AND_RUNTIME`)
+
+  注册表 tier 同步 `advisory` → `gating`。除 `os validate` / `os build` / `os lint` 之外,本规则也跑在
+  元数据写入路径的 publish 门上,`error` 会让 `state: 'active'` 的写入被拒(422)。**边界值得写清,因为
+  直觉猜错的方向恰好对租户有利**:该门交给规则的快照里 `flows` 只装**正在写入的那一个** item
+  (`runtime-gate.ts`:`candidate = { objects, [stackKey]: [item] }`),并且会减掉 baseline 已产出的
+  finding。所以:
+
+  - 发布 flow A **不会**因为已存储的 flow B 是死 flow 而被拒;租户既有的死 flow 继续被读取和服务
+    (ADR-0087 读路径不对称);
+  - 被拒的是**死 flow 自己的发布**(含再次发布),以及 CLI 侧 —— stack 里含死 flow 的包
+    `os validate` / `os build` / `os lint` 转红;
+  - draft 保存从不过门(#4463 D1),只有发布才过。
+
+  ## 迁移
+
+  修死 flow,不要降级规则:
+
+  - 描述符判不过 → 按 finding 里 `TimeRelativeTriggerSchema` 的原文改(它会点名该写的键);
+    描述符要 `{ object, dateField, 且 withinDays | offsetDays 恰好其一 }`。
+  - `timeRelative` 写成了 `'daily'` 这类节奏值 → 节奏是**同级兄弟键** `config.schedule`
+    (默认每日 08:00 UTC,通常可省),`timeRelative` 只描述扫哪些记录。
+  - `record-*` token 落在文法外 → 用 `record-{before,after}-{create,insert,update,delete,write}`;
+    「创建或更新」用 `record-after-write` 一条 flow 覆盖(#3427);多事件数组仍未支持(#3457),
+    按事件各写一条 flow。
+
+  仓内三个示例 app(showcase / CRM / todo)`os validate` 升级前后输出逐字一致、均通过,
+  本次升级不需要修改任何示例。
+
+- 2f1e2a5: feat(lint): null-guard 闸门覆盖 `requiredWhen`,其余各面按"绑定是否全量"逐一定案 (#4811)
+
+  #4763 的 null-guard 闸门只接了两面(对象校验规则、生命周期 hook `condition`),
+  其余各面留作"待定"。本次把"待定"收敛成一条**可判定的判据**,并按它逐面定案 ——
+  一个只覆盖部分面、又没有任何东西说出这件事的闸门,正是这一族缺陷本身的形状。
+
+  ## 判据:记录绑定是否对已声明字段**全量**
+
+  这不是口味问题,也不是"这个谓词是不是 CEL"。实测 `@marcbachmann/cel-js`,两种绑定
+  下的语义**恰好相反**:
+
+  | 谓词                  | 全量绑定 `{a: null}`     | 稀疏绑定 `{}`          |
+  | :-------------------- | :----------------------- | :--------------------- |
+  | `has(record.a)`       | `true` ← 陷阱            | `false` ← 真守卫       |
+  | `record.a < record.b` | FAULT `no such overload` | FAULT `No such key: a` |
+  | `record.a != null`    | `false` ← **修法有效**   | FAULT `No such key: a` |
+
+  即:全量绑定下 `has()` 恒真而无用、`!= null` 是解药;稀疏绑定下 `has()` 恰恰是正确的
+  守卫,而 `!= null` **自身就会 fault**。把闸门指向一个稀疏绑定的面,等于判红正确的元数据、
+  并给出一个会把它改坏的"修法" —— 比不覆盖更糟。所以:**只有绑定全量的面才可以接入。**
+
+  ## 纳入:字段 `requiredWhen`
+
+  议题没有列出这一面,而它恰恰是唯一满足判据的:`evaluateValidationRules` 用与对象校验
+  规则**同一个** `materializeDeclaredFields` 合并记录来求值 `requiredWhen`。
+
+  它也是几个已覆盖面里失败得最安静的一个:`requiredWhen` 谓词 fault 时是 **fail-open** ——
+  `rule-validator.ts` 记一行 `failed to evaluate — skipped` 就跳过,字段于是**从未真正必填**,
+  写入照常通过。校验规则至少自 #4761 起是 fail-closed 的拒绝。因此报错文案按面区分后果:
+  "被跳过、字段从未必填"与"写入被 fail-closed 拒绝"是两个相反的故障,作者需要知道自己
+  碰到的是哪一个。
+
+  ## 排除,且各自留下可引用的理由
+
+  - **action `visible` / `disabled`**:谓词确实走真 CEL(裸串经 `ExpressionInputSchema`
+    规范成 `{dialect:'cel'}` 信封,渲染器保留它),fault 也确实 fail-closed —— 陷阱在这一面
+    是真的。但绑定是客户端已取到的那条记录(详情读取,或只带列表视图投影列的一行),
+    `objectui` 这条路径上不存在任何物化步骤。稀疏绑定下 `!= null` 是错的修法。要覆盖它,
+    得先决定是否把该绑定做成全量 —— 那是平台契约改动,不是 lint 改动。
+  - **flow / edge `condition`**:议题记的理由(扁平作用域下裸标识符可能是 flow 变量)对本
+    模块**不成立** —— 它只解析 `record.<f>` / `previous.<f>`,从不解析裸标识符,而引擎无
+    条件绑定这两个根。真正的阻碍还是全量性:`record-change-trigger.ts` 把记录播种为
+    `{ ...inputDoc, ...after }`,没有 `materializeDeclaredFields`,所以写入未提及的已声明列
+    是**缺键**而非 null,`!= null` 会和它本要守卫的比较一样 fault。
+  - **字段 `readonlyWhen`**:与 `requiredWhen` 同一个字段、相反的结论 —— 它由
+    `stripReadonlyWhenFields` 求值,那里合并的是 `{ ...previous, ...data }`,从不物化。
+  - **`Field.formula`**:按产品判断排除,而非按本判据。formula 是 `value` 角色、天然可空,
+    `guard ? value : null` 是被祝福的写法(#3306)。是否强制守卫会改变"作者被允许写什么",
+    该由维护者决定,不是一个接线缺口。
+
+  判据、实测表与逐面台账写在 `validate-null-guards.ts` 的模块注释里,每条排除在它对应的
+  调用点也留了注释,并各配一条断言钉住。
+
+  ## 顺带修正:`field '?'`
+
+  诊断的字段名此前走 `Object.values(fields)`,把**名字键**丢掉了 —— 而名字键正是
+  `Field.text({…})` 这种(最常见的)写法产生的形状,于是这类对象上的每条字段级诊断都定位在
+  `field '?'`。名字只出现在 `where` 里时还能忍;现在报错正文要告诉作者改哪个字段,就不能忍了。
+
+- af96af6: fix(lint): `validateOrgAxisRedLines` reads the sharing-rule keys the spec declares — the ADR-0105 D6 red lines fired on nothing before (#4984)
+
+  The two ADR-0105 D6 red lines are declared `error` and gate `os validate` /
+  `os build` / `os lint`. On the sharing-rule path neither of them could fire.
+
+  `validateOrgAxisRedLines` read `rule.criteria ?? rule.filter` and
+  `rule.sharedTo ?? rule.recipient`. `SharingRuleSchema` is `.strict()` and its
+  declared keys are `condition` and `sharedWith`; all four names it was reading
+  exist only as **rejected aliases** in `sharingRuleUnknownKeyError`, the
+  prescription attached to the refusal message. The rule runs on the post-parse
+  stack (`input: 'parsed'`), so for every spec-valid stack those four properties
+  were `undefined`, `JSON.stringify(undefined ?? '')` was `'""'`, and the
+  `parent_organization_id` test was constantly false.
+
+  **This is a behaviour change: the rule previously never triggered.** Both red
+  lines are now live on the sharing-rule path:
+
+  | Authored shape                                                               | Before | After                                                                     |
+  | :--------------------------------------------------------------------------- | :----- | :------------------------------------------------------------------------ |
+  | `condition` reading `parent_organization_id`                                 | passed | `error` `org-axis-permission-inheritance` at `sharingRules[i].condition`  |
+  | `sharedWith` reading `parent_organization_id`                                | passed | `error` `org-axis-permission-inheritance` at `sharingRules[i].sharedWith` |
+  | `sharedWith: { type: 'business_unit' }` on a `tenancy.enabled: false` object | passed | `error` `org-axis-cross-org-bu-grant` at `sharingRules[i].sharedWith`     |
+
+  A stack that ships today keeps building unless it contains one of those three —
+  the shapes D6 forbids and the gate was meant to have been refusing all along.
+  The rejected aliases are deliberately **not** read: a rule spelling `criteria`
+  or `sharedTo` is refused by the schema's own parse with the canonical key
+  named, and a consumer must not tolerate what the producer's contract rejects.
+
+  `condition` is an `ExpressionInput`, so all three of its shapes are scanned —
+  the authored bare string, the parsed `{ dialect, source }` envelope, and the
+  compiled `{ dialect, ast }` form.
+
+  The rule's own tests were the reason this survived review: their fixtures used
+  the same rejected aliases, so the suite was green while the gate was dead. Every
+  sharing-rule fixture now goes through `SharingRuleSchema` before the lint sees
+  it, and every object fixture through `ObjectSchema` — a fixture that drifts from
+  the spec surface fails at the fixture instead of silently exercising a shape no
+  author can write.
+
+- 5b8f95b: fix(objectql,lint): enforce parent-scoped `readonlyWhen` on the server (#4889)
+
+  `readonlyWhen: P\`parent.status == 'paid'\``— the documented "once the header
+invoice is Paid, its lines are frozen" lock — was enforced **only in the client
+grid**. The server-side strip bound`record`and`previous`and had no`parent`at all, so every parent-scoped predicate faulted, took the fail-open branch, and
+the write landed anyway. On the reference app that meant one`PATCH` rewrote the
+  quantity and unit price of a settled invoice's line: HTTP 200, value persisted,
+  the grid still drawing the cell read-only. ADR-0057 D10 puts enforcement on the
+  server and makes the client courtesy; here only the courtesy layer enforced.
+
+  **`parent` is now bound on the write path.** For a detail object — one declaring
+  exactly one `master_detail` relationship — the engine resolves the master record
+  and binds it as `parent` before the strip runs, on both the single-id and the
+  bulk (`multi: true`) update paths. A repointing write is judged against the
+  master it _lands on_, not the one it leaves. The read is gated on the payload
+  actually touching a parent-scoped predicate (decided from the parsed CEL AST, so
+  a field named `parent_id` costs nothing), and the bulk path batch-reads the
+  distinct headers in one query rather than one per row.
+
+  **An unbindable scope no longer waives the lock.** A `readonlyWhen` that names a
+  root the operation could not bind now resolves to **locked** — the field is
+  stripped — instead of "not locked". "The platform could not check this" must not
+  mean "allowed" on a field the author declared frozen. This is deliberately the
+  narrowest possible carve-out from the fail-open policy the strip has always had:
+  a predicate that is merely _broken_ on the record (undeclared key, `null`
+  ordering overload, parse error, engine throw) still fails open exactly as
+  before, and `requiredWhen` / option `visibleWhen` are untouched. Recorded as an
+  addendum to ADR-0058's D5 fail-policy matrix, alongside the same narrowing
+  already made for validation predicates (#4649) and hook conditions (#4775).
+
+  **And the runtime branch is a backstop, not the plan.** `objectstack compile`
+  now **rejects** a `parent`-scoped `readonlyWhen` on an object that declares no
+  `master_detail` relationship, or two of them (where the metadata does not say
+  which one is "the parent" and picking by declaration order would make a
+  data-integrity lock depend on field ordering). The common authoring mistake is
+  caught where it is cheap to fix, so it never reaches a runtime that has to judge
+  it — declared, not guessed.
+
+  No metadata changes are required: an app whose parent-scoped locks were already
+  correct simply starts having them enforced. If you authored one on an object
+  with no single master, the build now names it.
+
+- 73580e7: feat(lint): the react-page publish gate PARSES `ChartAggregateSchema` instead of re-deriving it (#5020)
+
+  `<ObjectChart aggregate={{…}}>` is judged at publish time by
+  `validate-react-page-props`. That gate used to RE-DERIVE the aggregate's
+  declaration: a local `CHART_FUNCTIONS` copy of the function vocabulary and a
+  hand-written twin of the schema's count/field refinement. Two implementations of
+  one contract, each free to drift — and, because unknown-key handling is a
+  property of a **parse** rather than of a list of `if`s, a gate with no
+  unknown-key check at all. The rule now calls `ChartAggregateSchema.safeParse()`
+  on a statically resolvable literal, exactly as #5022 did for
+  `ChartDrillDownSchema` beside it, and both hand-derived copies are deleted:
+  `@objectstack/spec` is the single source of the vocabulary and the refinement
+  again.
+
+  **Newly reported (all `error`, all previously silent).** These are shapes the
+  schema, the published react-blocks type and objectui's renderer already agreed
+  were wrong; the old gate simply could not see them:
+
+  | authored                                                            | before   | after                                                                                                            |
+  | ------------------------------------------------------------------- | -------- | ---------------------------------------------------------------------------------------------------------------- |
+  | `aggregate={{ field: 'total', groupBy: 'status' }}` (no `function`) | accepted | `aggregate.function: Invalid option: expected one of "count"\|"sum"\|"avg"\|"min"\|"max" (nothing is set there)` |
+  | `aggregate={{ field: 42, function: 'sum', groupBy: 'status' }}`     | accepted | `aggregate.field: Invalid input: expected string, received number`                                               |
+  | `aggregate={{ function: 'count', groupBy: 42 }}`                    | accepted | `aggregate.groupBy: Invalid input (received 42) — no accepted form matched: (1) … (2) …`                         |
+  | `aggregate="count"` / `aggregate={[]}`                              | accepted | `aggregate must be a configuration object, not string.`                                                          |
+
+  **Re-worded, same verdict.** Two messages now arrive from the schema rather than
+  from this rule's own copy. If you match on lint output, update the text:
+
+  - FROM `aggregate.function "median" is not an aggregation this chart can run.`
+    (hint: `Use one of: count, sum, avg, min, max.`)
+    TO `aggregate.function: Invalid option: expected one of "count"|"sum"|"avg"|"min"|"max" (received "median")`
+    — the vocabulary is the enum's own, and the author's value is echoed back from
+    the input (the one part zod does not put in the message).
+  - FROM `aggregate.function "sum" has no "field" to aggregate.`
+    TO `aggregate.field: aggregate.function "sum" needs a "field" to aggregate (only "count" may omit it).`
+    — verbatim from the schema's refinement.
+
+  The rule id (`react-chart-aggregate-invalid`) and the severity are unchanged for
+  both.
+
+  **`aggregate.groupBy` missing is a NEW `warning`, deliberately not an error.**
+  It is the one violation the platform does not agree with itself about:
+  `ChartAggregateSchema` and the published react-blocks type both declare `groupBy`
+  **required**, while objectui's `ObjectChart` honours its absence
+  (`schema.aggregate?.groupBy || schema.xAxisKey`) and this protocol's own
+  `chartAggregateCategoryKey` documents the ungrouped single-row result. Gating it
+  would break a working authoring shape to enforce a declaration the platform does
+  not keep, so the finding explains the situation and does not fail
+  `os lint`/`validate`/`compile`. Whether the schema loosens or the renderer
+  tightens is decided on #5583.
+
+  **What this does NOT fix yet.** `ChartAggregateSchema` and `ChartGroupBySchema`'s
+  object arm are still STRIP-posture, so the parse this gate now runs **drops** an
+  unknown key rather than reporting it: `groupby` for `groupBy` and
+  `dateGranularty` for `dateGranularity` still degrade a chart to one ungrouped
+  point with the build green. Wiring the parse is the precondition for closing
+  that, not the closing — `.strict()` is a property of a parse, and until now there
+  was no parse to make strict. The spec-side tightening is **#5583**; the tolerance
+  is pinned by name in this rule's tests so a wired gate cannot be mistaken for a
+  closed one (#4583).
+
+- bf1edef: feat(formula,lint): wire ADR-0056 D4's RLS authoring gate, from the runtime's own predicate (#4983)
+
+  `isSupportedRlsExpression` has carried the same docblock since ADR-0056 D4:
+  "exposed so an authoring-time gate (`objectstack compile`) can REJECT a
+  predicate the runtime would silently drop … A `false` here means 'this
+  predicate will never enforce'." It had **no non-test consumer anywhere** — the
+  function written to fix declared-but-never-read was itself declared and never
+  read. This lands the consumer, in two steps that had to happen in this order.
+
+  **1. `sqlPredicateToCel` and `isSupportedRlsExpression` move FROM
+  `@objectstack/plugin-security` (`src/rls-compiler.ts`) TO `@objectstack/formula`
+  (`src/rls-predicate.ts`), and are exported from its root.** Executable code
+  unchanged — a change of address, not of behaviour; `plugin-security` now imports
+  them from `@objectstack/formula` and keeps no copy, so there is still exactly
+  one definition. No import path outside the two packages changes: neither symbol
+  was ever exported from `@objectstack/plugin-security`'s entry point. The move is
+  what makes step 2 possible at all — `@objectstack/lint` may depend on
+  `@objectstack/spec` and never on a runtime, so with the predicate living in a
+  runtime the gate's only other door was copying the SQL→CEL bridge, whose
+  boundary conditions (quoted literals are never rewritten; canonical CEL passes
+  through unchanged) _are_ the gate's red/green line. A fork drifting by one
+  character rejects policies the runtime executes correctly — the false-positive
+  direction, which is worse than the gap. ADR-0058 D1 asks for a single canonical
+  shape gate; the bridge is part of that gate.
+
+  **2. New `@objectstack/lint` rule `validateRlsPredicateEnforceability`,
+  `error`, on all three authoring commands**, over
+  `permissions[].rowLevelSecurity[].using` and `.check`:
+
+  - **`rls-predicate-unenforceable`** — parses as CEL, outside the pushdown
+    subset: a function call (`size(...)`, `has(...)`), arithmetic, a ternary, a
+    cross-object path (`record.account.region`).
+  - **`rls-predicate-unparseable`** — does not parse as CEL even after the legacy
+    SQL bridge (`=` → `==`, `IN` → `in`): SQL `AND` / `OR` / `LIKE`, a subquery.
+    Its own id because the fix is different — write CEL (`&&`, `||`), not a
+    different shape.
+
+  What the gate prevents, measured through `plugin-security` rather than inferred:
+  `RLSCompiler` drops the policy and logs one request-time WARN. On the read path,
+  when it is the only applicable policy, `compileFilter` returns the
+  `RLS_DENY_FILTER` sentinel instead, which is AND-ed onto the where clause — so
+  every select / update / delete on the object matches **zero rows**. On the
+  ADR-0058 D4 write path the post-image `check` becomes that same sentinel, which
+  no record satisfies, so every insert / update fails with `PermissionDeniedError`.
+  The runtime fails closed, which is why this was survivable: the result is not a
+  hole but a policy that reads as an authorization and behaves as a blanket
+  refusal, with nothing at authoring time pointing at the line that caused it.
+
+  Fix a flagged predicate by rewriting it inside the lowerable subset — `==` `!=`
+  `>` `<` `>=` `<=`, `in`, `&&` `||` `!`, `== null` / `!= null`, and
+  `startsWith` / `endsWith` / `contains` over single-column field paths (ADR-0058
+  D2), against a literal or a `current_user.*` value. Two specific migrations:
+  `has(x)` / `size(x) > 0` → `x != null` (a function call is correct in an object
+  _validation_ rule, which is interpreted, and wrong here, where the predicate is
+  compiled to a filter); and a related record's field → denormalise it onto this
+  object (formula/rollup) and test that column, since RLS cannot join (ADR-0055).
+
+  Same construction as the sharing-rule gate (#4698): the rule does not model the
+  consumer or grep for it — it calls `isSupportedRlsExpression`, the exact
+  function `RLSCompiler.compileFilter` consults to decide whether a dropped policy
+  earns its warning, so the two verdicts are one boolean by construction, pinned
+  in both directions over a shared corpus. Measured before shipping: every RLS
+  predicate declared anywhere in this repo — the `plugin-security` platform seeds,
+  the examples, the dogfood fixtures, the authoring skill — is supported, so the
+  gate turns nothing red that works today. Unlike the sharing-rule gate, CEL
+  _syntax_ is reported here rather than deferred to `expression-invalid`:
+  `validateStackExpressions` does not walk `rowLevelSecurity` at all, and could not
+  judge this field correctly if it did, because `owner_id = current_user.id` is a
+  CEL syntax error and a working RLS predicate at the same time.
+
+- 73e576f: feat(lint,spec): SDUI 组件 props 接上解析闸门 —— `ComponentPropsMap` 不再是「声明了、从不被 parse」(#5068)
+
+  `PageComponent.properties` 是 `z.record(z.string(), z.unknown())` 这个开放口袋。
+  `PageComponentSchema` 自 ADR-0089 D3a 起是 `.strict()`,但**严格性不递归**:它守住
+  component 节点自己的键,`properties` 里面一个字都没人看。于是 `ComponentPropsMap`
+  里 31 个 typed props schema 从来没有被任何东西 parse 过(#4001 批 17 的 `no gate`
+  判定:载体活着、parse 缺席)。后果不是无害的 —— objectui 的 `SchemaRenderer` 会把
+  `properties` 整个 hoist 到节点上,再把 deny-list 之外的每个键 spread 成 React prop,
+  所以一个拼错的键既不被拒绝也不被丢弃:它一路走到渲染器,在那里被忽略,而作者拿到
+  的是一张成功回执。这正是 ADR-0078 要消灭的形状。
+
+  **新规则(两个诊断 id,均为 warning 级)**,落在 `@objectstack/lint`,按维护者对
+  #5068 的裁定走方向 A —— 在载体自己的授权门上分派解析,而不是改 `page` 协议的形状:
+
+  - **`component-props-unknown-key`** —— props schema 未声明的键,包括 props 包自身
+    这一层和它底下每一个 strip 姿态的对象。走的是 `lintUnknownKeysAgainstSchema`
+    (本次从 `@objectstack/spec` 导出,即 `lintUnknownAuthoringKeys` 用在每个 metadata
+    集合上的同一个 walker),所以 strip/strict/passthrough 的姿态规则与改名建议都是
+    单一实现,这里不重新推导一遍。
+  - **`component-props-invalid`** —— props schema 拒绝的值:类型不对、必填缺失、枚举
+    越界。
+
+  配套的一条契约细节:走到第二层。`readonly`(#5176)挂在 `RecordHighlightsField`
+  联合体的对象成员上,即 `fields[]` 数组项里面 —— authorable-surface walk 严格一层、
+  到不了那里(#5607 的更正)。本闸门到得了,并且两个方向都钉了测试:声明过的
+  `readonly` 必须静默,拼错的 `readOnly` 必须报出来并指名正确拼法。
+
+  **未注册 type 一律跳过**,这是必须语义而不是宽松:`PageComponentSchema.type` 是
+  `z.union([PageComponentType, z.string()])`,光是仓内 example 语料就授权了 10 种本
+  map 不承载的类型、共 87 个节点(`flex`、`grid`、`object-metric`、`object-chart`、
+  `record:line_items` …),它们的契约在 objectui 注册表和 ADR-0080 manifest 里。拿一个
+  不存在的 schema 去审判它们,只会把每一个都报成坏的。
+
+  **为什么本步只落 warning。**接上 parse 是执法的前置条件,不是执法本身(#5020 在隔壁
+  表面上的同一课)。闸门落在真实语料上会报 52 条:其中 34 条是三个已发布平台页把
+  `{ en, 'zh-CN' }` 内联多语言 map 写进了声明为纯 `z.string()` 的 `I18nLabelSchema`
+  (#5728,裁定中),另有 8 条是 `element:text.content` 上同一形状。今天就 gate 掉它们,
+  等于用平台自己都不遵守的声明去否掉平台自己的页面。warning 期的违例清单就是 error
+  升级的验收基线,升级本身是独立一步。
+
+  作者侧不变:`properties` 仍然照原样解析、原样保留,没有任何东西开始被拒绝 ——
+  `os validate` / `os build` / `os lint` 多了一类建议性诊断而已。存储路径(`saveMetaItem`
+  / REST `/meta`)仍然不校验 props 包,这一点被如实记录、未在本次修复。
+
+- ddd6650: feat(lint): reject a sharing-rule condition the runtime can only skip (#4698)
+
+  #4698 reported the same failure shape three times in one app in one day: a key
+  that is authored, is schema-valid, reads as meaningful — and is never consumed
+  by the runtime. Every check verifies that what is declared is _well-formed_,
+  never that it is _read_. The issue's third measured instance is a sharing rule
+  whose CEL `condition` uses `has(...)`: the seeder cannot lower it, skips the
+  rule, and the only signal is one WARN line at boot. The rule exists in
+  metadata, is absent from `sys_sharing_rule`, and grants nothing.
+
+  **New rules, both `error`, on all three authoring commands:**
+
+  - **`sharing-rule-unlowerable-condition`** — the condition is outside the
+    pushdown subset: a function call (`has(...)`, `size(...)`), arithmetic, a
+    ternary, or a cross-object path (`record.account.region`).
+  - **`sharing-rule-runtime-variable-condition`** — the condition reads
+    `current_user.*`. Criteria sharing rules are materialised (one static
+    `criteria_json` per rule, from which grants are written), so there is no
+    "current user" at compile time. The fix is a different mechanism, not a
+    different spelling, which is why it has its own id.
+
+  Fix each by rewriting the predicate inside the lowerable subset — `==` `!=`
+  `>` `<` `>=` `<=`, `in`, `&&` `||` `!`, `== null` / `!= null`, and
+  `startsWith` / `endsWith` / `contains` over single-column `record.<field>`
+  paths (ADR-0058 D2). Two specific migrations: `has(record.x)` → `record.x !=
+null` (`has()` is correct in an object _validation_ rule, which is
+  interpreted, and wrong here, where the condition is compiled); and a related
+  record's field → denormalise it onto this object (formula/rollup) and test
+  that column, or share the related object instead. For per-user access, use an
+  RLS policy (`rowLevelSecurity[].using`), where `current_user.*` _is_ resolved.
+
+  **Why this one surface and not "unread keys" in general.** "Is this key read?"
+  is only a lint question when the answer is computable from the authored
+  metadata alone, and usually it is not — a repo-wide grep for a reader is not
+  evidence of absence, and a consumer may live in another package, another repo,
+  or an uninstalled plugin. A sharing rule's `condition` is the case where the
+  predicate is exact: its one runtime consumer
+  (`bootstrapDeclaredSharingRules`) does exactly one thing with the key —
+  `compileCelToFilter(condition, { variables: {} })` — and a condition that does
+  not lower means the rule is skipped outright. So the lint calls that same
+  compiler, from the same package, with the same options, instead of modelling
+  the consumer; the verdict is identical to the seeder's by construction and is
+  pinned in both directions by a test over a shared corpus.
+
+  `error` rather than advisory, per the ADR-0078 claim `SharingRuleSchema`'s own
+  docblock makes ("the whole authorable surface is enforced — nothing here
+  validates and then silently does nothing"): there is no reading under which an
+  unlowerable condition does what it says. It fails closed, which is why it was
+  survivable, not why it was acceptable. Measured before shipping: every
+  sharing-rule condition declared anywhere in this repo lowers cleanly, so the
+  gate turns nothing red that works today.
+
+  CEL _syntax_ errors are deliberately left to `expression-invalid`, which
+  already gates this same field with a message written about syntax.
+
+- 1e6ab15: feat(lint): uniqueness-scope rules speak the ADR-0120 vocabulary (#4986, D5a/D5b)
+
+  - **New rule `unique/unscoped-declared-index`** (warning, advisory): a declared
+    index with bare `unique: true` — the spelling whose scope is unstated, the
+    #4986 trap. Fires on the spelling alone (no tenancy/posture inference —
+    `organization_id` is kernel-injected at registration, so an authoring-time
+    guess would be wrong half the time; see #4698). The fix names both words:
+    `'global'` (installation-wide — exactly today's behavior) or
+    `'organization'` (one holder per organization). Protocol 18 rejects the
+    spelling (#5082). Exported as `lintUnscopedDeclaredIndexes` +
+    `UNIQUE_UNSCOPED_DECLARED_INDEX`, registered as its own AUTHORING_RULES
+    entry (validate/build) and called by `lintDataModel` for `os lint`, so all
+    three commands report it — each finding exactly once.
+  - **R10 `unique/double-declaration` rewritten as the four-quadrant scope
+    matrix** (ADR-0120 D5b): field `true`/`'organization'` × declared `'global'`
+    (or bare `true`, its deprecated spelling) on the same single column =
+    CONTRADICTION (the installation-wide index wins physically; the
+    per-organization intent is silently dead) — and the mirror, field `'global'`
+    × declared `'organization'`, likewise; same scope on both sides = REDUNDANCY
+    (the same index declared twice). The old field-`'global'` exemption is gone
+    (now reported as redundancy), and the fix text replaces the hand-written
+    `fields: ['organization_id', …]` advice with the `'organization'` spelling —
+    the hand-written composite is not NULL-safe (#5030).
+
+### Patch Changes
+
+- c1e67e0: fix(lint): 扩 ADR-0105 D6 ② 的收件人词表至 ADR 原文范围 —— `unit_and_subordinates`
+  也判红
+
+  `org-axis-cross-org-bu-grant`(D6 ②)此前只对 `sharedWith.type ===
+'business_unit'` 判红,而授权面**更大**的另一个业务单元收件人
+  `unit_and_subordinates`(一个 BU **加上其全部后代单元**,ADR-0057 D5 子树扩张)
+  直接放行。两者的缺陷完全相同:平台级对象(`tenancy.enabled: false` /
+  `systemFields.tenant: false`)没有 organization 列可供 Layer 0 收口,BU 子树没有
+  任何 organization 可供解析,授权因而跨到库里每一个 organization —— 正是 ADR 拒绝
+  的"跨 org BU 巨树",从后门到达。
+
+  漏掉的恰恰是 ADR-0105 D6 ② 自己点名的那一个:
+
+  > Every BU mechanism — `unit_and_subordinates` sharing, `adminScope`
+  > delegation, depth scopes — operates within one organization. There is no
+  > cross-org tree.
+
+  判定改为收件人类型 ∈ `{ business_unit, unit_and_subordinates }`,诊断信息里点名
+  **实际写下的**类型并说明其触及范围(子树那一个额外写明 "AND every descendant
+  unit"),修复建议改为指向三个扁平收件人。
+
+  词表与 spec 枚举 `ShareRecipientType` 的差集不再是隐式的:规则里以表格逐条写明
+  拦截二者、放行 `user` / `team` / `position` 的理由(它们的运行时展开都不经
+  `BusinessUnitGraphService`,是 `tenancy.enabled: false` 平台级目录**被设计用来**
+  共享的方式),并附一条测试断言两半恰好划分 `ShareRecipientType` —— 将来枚举加成员
+  会在词表处失败,而不是无声地落进没人选过的那一桶。#4991 正是这条断言缺席的产物。
+
+  这是 error 级门禁的扩张,因此复核了真实元数据:`examples/app-showcase` /
+  `app-crm` 是仓库里仅有的已声明 sharing rule(共 11 条),全仓无任何对象关掉
+  tenancy,扩张后 org-axis 红线数为 **0** —— 不产生新红。
+
+- 641363a: fix(docs,lint): 修正两处裸引用公式样例,并给公式样例补一道 CEL 语义门 (#5116)
+
+  #5026 把字段公式校验从 `f.formula`(spec 按名拒绝的别名)收敛到声明的
+  `f.expression`,**激活了一条从未跑过的检查**。它的真实元数据扫描顺带发现文档和博客
+  里有两处公式样例写的是**裸引用**:
+
+  - `content/docs/data-modeling/fields.mdx` — `'quantity * price * (1 - discount / 100)'`
+  - `content/blog/context-window-is-the-constraint.mdx` — `` cel`amount * probability`  ``
+
+  裸引用在 CEL 里不报错,而是**静默求值为 null**:公式表达式把记录绑定在 `record`
+  命名空间下,顶层的 `quantity` 什么也解析不到。照这两行写出来的元数据,在 #5026
+  之后会被 `os build` / `os validate` 判红 —— 文档教的写法和平台的门直接矛盾。两处
+  都已改成 canonical 的 `record.` 前缀形式。
+
+  **新增 `@objectstack/lint` 的 `check:doc-formula-expressions`**,堵住让这两条长期
+  存活的那个洞。`check:doc-authoring` 看的是字面量的**形状**,`check:skill-examples`
+  对标记块跑 `tsc --noEmit` —— 两者之间,"能编译但 CEL 写错"的样例没有任何门:
+  `expression` 的类型就是 `string`,`'quantity * price'` 和
+  `'record.quantity * record.price'` 编译得一样好,而只有后者能用。
+
+  判决直接 import `@objectstack/formula` 的 `validateExpression` —— 和 `os build`
+  走的是同一个调用,不是仿制品。于是文档是被**规则本身**把关,而不是被规则的一种方言
+  把关(Prime Directive #12)。
+
+  门的难点不在判决而在**判据**:同一个 `expression:` 键在语料里承载至少三种互不相干的
+  契约 —— 记录作用域的 CEL 公式、flow 的扁平作用域谓词(那里裸引用是**对的**)、以及
+  `schedule` 下压根不是 CEL 的 cron 串。按键名匹配会把后两类全部误判为红。所以它只认
+  **解析后的结构**,且只认两种不可能有歧义的形状:`Field.*({ expression })`,以及
+  `type: 'formula'` 与 `expression` 并列的对象字面量。无法提取的块**报错而不是跳过**
+  ("absence must be loud")。
+
+  覆盖面是明说的,不含糊:只看 TS/TSX 代码块、只看能静态取出的表达式源、不做字段存在性
+  校验(文档片段没有对象声明)、flow / action / validation 谓词**刻意不在范围内**。
+
+- d4edb5d: fix(lint): the flow rule family now descends into `loop` bodies and every other nested region (#5383)
+
+  The flow anti-pattern rules read a flow's `nodes` / `edges` **flat off the top
+  level**, so every rule in the family was blind to anything authored inside an
+  ADR-0031 container — a `loop` body, a `parallel` branch, a `try_catch`
+  try/catch. Loop bodies are where a lot of real branching lives (a per-item gate
+  inside a sweep is the standard shape for a scheduled flow), so this was a large
+  share of authorable flow metadata that no flow rule inspected.
+
+  Measured in a real app: 8 `decision` nodes carried the inert singular
+  `config.condition` that `flow-inert-node-condition` exists to catch, all 8
+  inside a `loop` body, and `pnpm lint` reported none of them. The identical key
+  on a **top-level** decision in the same repo fired immediately — same key, same
+  node type, only the nesting depth differed. The blind spot also explains its own
+  survival: the gate visibly worked where it could see, so the top-level copies
+  got cleaned up while the nested ones read as approved.
+
+  Rules now reported at every depth: `flow-inert-node-condition`,
+  `flow-decision-unconditional-branch`, `flow-branch-label-unmatched`,
+  `flow-default-edge-with-condition`, `flow-multiple-default-edges`,
+  `flow-double-brace-interpolation`, `flow-bare-dollar-reference`,
+  `flow-date-equality-filter`, `flow-phantom-aggregation`,
+  `flow-error-label-not-fault`, and the `flow-approval-revise-*` family. Note the
+  severity asymmetry this closes: `flow-default-edge-with-condition` is a
+  build-stopping `error` that until now could not see a contradiction authored one
+  level down.
+
+  A finding inside a region carries the region scope in its `where`, so the
+  message still points at exactly one node — `flow 'x' · loop 'sweep' body ·
+node 'y' (decision)`, matching the scope vocabulary the engine's registration
+  pass already uses. Findings on a flow's own graph are unchanged, byte for byte.
+
+  Two details worth knowing if you consume these findings:
+
+  - Each region is scanned against **its own** `edges`. The branch-routing rules
+    reason about a node together with its out-edges, and a region is a
+    self-contained sub-graph, so a nested decision's out-edges live in the
+    region's own edge list.
+  - `flow-double-brace-interpolation` / `flow-bare-dollar-reference` scan a node's
+    config recursively, and a container's config physically contains its
+    descendants'. A nested hit was therefore already _visible_ before this change
+    — but attributed to the enclosing `loop` rather than the node carrying the
+    string. Such a finding now names the right node, and is still reported exactly
+    once.
+
+  `flow-runas-unscoped` deliberately keeps looking at top-level nodes only:
+  widening a build-gating rule is its own change with its own blast radius, and is
+  tracked separately.
+
+- eb26126: fix(lint): `flow-runas-unscoped` now sees data nodes nested in a `loop` body / `parallel` branch / `try_catch` region (#5633)
+
+  **This widens the coverage of a build-GATING rule.** `flow-runas-unscoped` is
+  `severity: 'error'`, so a flow it newly catches goes from a green build to a
+  failed one. That is the correct outcome — those flows cannot run at all — but it
+  is a real blast radius and the reason this shipped as its own change rather than
+  riding along with #5383.
+
+  **What was wrong.** #5383 gave the flow anti-pattern family a per-region walk and
+  deliberately left this one rule reading the flow's **top-level** `nodes` only. Its
+  data-node search is the rule's evidence that the flow _performs a data operation
+  at all_ — and a data node inside a `loop` body is exactly as unscoped as one at
+  the top level. So a scheduled flow that queried a set, looped it, and wrote per
+  item passed `os build` / `os validate` clean and was then **refused at run time**:
+  since #3760 a user-less run really does refuse the data operation rather than
+  running it unscoped. Passing the build and then being unable to run is precisely
+  what promoting this rule to `error` was for, and the shape it was missing —
+  query, loop, write per item — is _the_ standard shape for a scheduled flow, so
+  the write is almost always the nested node.
+
+  Measured, same flow with only the node's position changed:
+
+  ```
+  update_record at TOP level     -> 1 finding [error]
+  update_record INSIDE loop body -> 0 findings   (now: 1 finding [error])
+  ```
+
+  **What changed.** The data-node search runs across `collectFlowGraphs(flow)` —
+  every ADR-0031 region, at any depth — while the finding itself stays **flow-level**
+  exactly as before: one per flow, `where` = `flow 'x' · runAs`, because `runAs`
+  is a flow property and the region only supplies the evidence. The region is named
+  in the **message** so you can find the node:
+
+  ```
+  flow 'nightly_sweep' · runAs: schedule-triggered flow runs under `runAs:'user'`
+  (the default when none is declared), but a schedule run has no trigger user — so its
+  data node 'touch' (update_record), in loop 'loop_rows' body, has no identity to scope
+  to and will be REFUSED at run time.
+  ```
+
+  (The sentence's opening was re-worded by #5693 in this same release window; the
+  sample above is the wording that actually ships.)
+
+  **Nothing about the top-level case moved.** A flow whose evidence is a top-level
+  data node produces the same message with no region clause, and when a flow has
+  data nodes at both altitudes the top-level one is still the node cited —
+  `collectFlowGraphs` yields the flow's own graph before it descends. Both are
+  pinned by tests.
+
+  **If this newly fails your build:** the flow was already broken at run time. Add
+  `runAs: 'system'` to declare the elevation the sweep needs (a schedule /
+  time-relative / API run has no user to scope to — there is none). See ADR-0049,
+  ADR-0073 D5, #1888, #3760.
+
+  The repo's three example apps (`app-showcase`, `app-crm`, `app-todo`) are
+  unaffected — `os validate` output is line-for-line identical before and after.
+
+- be59695: fix(lint): `flow-runas-unscoped` stops telling an author they declared a `runAs` they never wrote (#5693)
+
+  The rule's message branched on whether `runAs` was **authored** or **defaulted**:
+
+  ```ts
+  typeof flow.runAs === "string" ? `runAs:'user'` : `the default runAs:'user'`;
+  ```
+
+  That distinction is real and useful — "you wrote something incoherent" is not
+  "you inherited a default that does not fit a user-less trigger" — but the rule
+  cannot observe it, and which arm an author got depended on the **surface** rather
+  than on their file.
+
+  **On the CLI, only the explicit arm was reachable.** `FlowSchema.runAs` carries
+  `.default('user')` and the registry wires this rule `input: 'parsed'`, so
+  `flow.runAs` is the string `'user'` whether the author wrote it or not. `os lint`
+  does not Zod-parse, and would have escaped that — except `defineStack` /
+  `defineFlow` parse at _definition_ time, so the config module hands even the
+  non-parsing command a stack with the default already filled in.
+
+  Measured on `examples/app-todo`, `overdue_escalation` with its `runAs` line
+  deleted — the author declared nothing:
+
+  ```
+  BEFORE — os validate
+    flow 'overdue_escalation' · runAs: schedule-triggered flow runs as `runAs:'user'`, but a
+    schedule run has no trigger user — so its data node 'get_overdue_tasks' (get_record) …
+
+  BEFORE — os lint
+    ✗ flow 'overdue_escalation' · runAs: schedule-triggered flow runs as `runAs:'user'`, but a
+    schedule run has no trigger user — so its data node 'get_overdue_tasks' (get_record) …
+  ```
+
+  Both commands told someone who had written no `runAs` that their flow "runs as
+  `runAs:'user'`" — which invites _"I never wrote that, the tool is confused"_ at
+  exactly the moment the tool is right and the fix is one line away.
+
+  Meanwhile the **runtime publish gate** (#4463) judges the verbatim authored body,
+  so it really did reach the other arm — the same flow was told two different
+  things by two shipped surfaces.
+
+  **What changed.** One sentence, true of both authoring inputs, on every surface:
+
+  ```
+  AFTER — os validate and os lint, identical
+    flow 'overdue_escalation' · runAs: schedule-triggered flow runs under `runAs:'user'`
+    (the default when none is declared), but a schedule run has no trigger user — so its
+    data node 'get_overdue_tasks' (get_record) has no identity to scope to and will be
+    REFUSED at run time.
+  ```
+
+  The parenthetical is a statement about the **value**, not an accusation about the
+  author, so it stays true for someone who did write `runAs:'user'`. This is the
+  house pattern rather than a new one: `flow-draft-status-ambiguous` says `has
+status 'draft' (the default when none is authored)` for the same reason, on the
+  same mechanism.
+
+  Only the wording moved: the same flows are flagged, with the same
+  `severity: 'error'`, the same `where`, the same `hint`, and the same region
+  clause when the evidence node is nested.
+
+- b2e1057: fix(lint): report a `config.timeRelative` descriptor the sweep will refuse, at authoring time (#5496)
+
+  A flow start node declaring `config.timeRelative` got **zero** authoring-time
+  diagnostics when its descriptor could not parse. The two rules that look at the
+  slot each looked at something else: `lint-flow-patterns` decides "this is a
+  time-relative flow" from `timeRelative != null` alone (never the shape), and
+  `validate-flow-trigger-readiness`'s existing check reads only
+  `timeRelative.object`, to compare it against the stack's objects. So
+
+  ```ts
+  config: { timeRelative: { object: 'task', field: 'due_at', offsetDays: -1 } }
+  ```
+
+  — three separate schema violations: `dateField` missing, `offsetDays` declared
+  as an int **array** and written as a scalar, and `field` an unrecognized key —
+  passed `os validate` silently. `TimeRelativeTriggerSchema` does reject it, but
+  the only place that schema ran was **bind time**, inside
+  `TimeRelativeTriggerPlugin.start()`, which warns and returns: the sweep is never
+  installed, the flow reports itself armed, and the author's sole feedback is one
+  line in a server log. For an AI author that line is outside the feedback loop
+  entirely; `os validate` is what it reads.
+
+  **New rule — `flow-time-relative-descriptor-invalid` (warning).** A start node
+  whose `config.timeRelative` is present runs that same schema at authoring time,
+  and a failure is reported naming `config.timeRelative` with the schema's own
+  issue list forwarded — so the diagnostic carries the missing key, the wrong type,
+  and, for an unrecognized key, the "did you mean" the schema already computes
+  (`field` → `dateField`) plus its wrong-layer guidance (a `schedule` written
+  _inside_ the descriptor is told it belongs beside it). The list is rendered
+  exactly as the bind-time warning renders it, so the two channels tell one story.
+
+  Nothing is shifted except **when** the schema runs. No shape knowledge is
+  re-implemented in the rule and no consumer-side tolerance is added: the verdict
+  and every word of its wording remain `TimeRelativeTriggerSchema`'s, so the rule
+  tracks the descriptor's contract as it evolves instead of drifting from a second
+  copy of it.
+
+  The rule and the existing object-name check decide different facts and cannot
+  report the same one twice — only the stack knows whether an object name exists,
+  and only the schema knows the descriptor's shape. A descriptor wrong in both ways
+  gets both findings, at their own paths. Canonical descriptors are unaffected:
+  every one shipped in the repo (the showcase `Task Due Reminder`, the
+  `content/docs` examples) parses, so this adds no diagnostic to existing apps.
+
+- ec6fad8: feat(lint): warn when a `multi: true` delete/update is bounded by nothing — the declared whole-object write (#5482)
+
+  A `delete_record` / `update_record` node that declares `multi: true` with no
+  `filter` (or an empty one) writes the **whole object**: the executor forwards
+  `where: {}` plus the bulk intent, the data engine classifies that as a legal
+  `multi` call, and it lands on `driver.deleteMany` / `driver.updateMany` with no
+  predicate. Every row, every run.
+
+  That path only became authorable with #5393, which gave these nodes a bulk
+  declaration at all — before it the executor never passed `options.multi`, so the
+  engine refused every predicate write (`Delete requires an ID or
+options.multi=true`) and "empty filter + bulk intent" was not a reachable shape.
+  Since then it has been reachable and **silent**: `filter` is optional, `multi` is
+  optional, nothing related the two, and the author's only feedback was the step's
+  `acted` row count — reported after the rows were gone. The common way to get
+  here is not malice but an omission: declaring the bulk intent and forgetting the
+  constraint.
+
+  `os validate` / `os build` now report `flow-multi-write-unfiltered` for it:
+
+  ```
+  flow 'nightly_purge' · node 'purge' (delete_record)
+    declares `multi: true` with no `filter` key — this is a WHOLE-OBJECT write,
+    by declaration: every row of 'lead' is deleted on every run. …
+  ```
+
+  **A warning, not a gate.** An explicit whole-object purge is something the
+  platform grants on purpose — the data engine's own dispatch case-set lists "bulk
+  intent with no predicate at all" as a valid call — so the shape has a legitimate
+  reading and the run-time path stays open. What was missing was only that the
+  author hears about it _before_ the rows go. For the same reason the fix is not a
+  schema `refine`: forbidding the shape would delete an intent the engine grants.
+
+  Two ways to satisfy the warning: write the constraint you mean into `filter`
+  (the bounded-bulk reference shape is app-showcase's `showcase_inquiry_purge`), or
+  confirm that emptying the object is the intent and keep it.
+
+  **It does not duplicate the #3810 run-time guard, which judges a different
+  fact.** That guard refuses a node when a condition the author _wrote_
+  interpolated to nothing (`{record.ownr}` — a typo — leaving `{}`), and it is
+  deliberately keyed on "a written condition is gone" rather than on "the filter is
+  empty", because losing one of two conditions also widens the blast radius. So:
+
+  | fact                          | judged by          | when      | verdict |
+  | ----------------------------- | ------------------ | --------- | ------- |
+  | a written condition vanished  | #3810 filter guard | run time  | refuse  |
+  | no condition was ever written | this rule          | authoring | warn    |
+
+  A node with `filter: { owner: '{record.ownr}' }` is silent for this rule (a
+  condition _is_ written) and refused by that one; a node with no `filter` at all
+  is warned about here and — correctly — allowed there. The diagnostic names the
+  run-time guard so the two are not mistaken for one check.
+
+  Reported at every nesting depth, which matters because a scheduled sweep whose
+  per-item work sits in a `loop` body is the standard janitor shape: a finding
+  inside a region carries the region scope (`flow 'x' · loop 'sweep' body · node
+'purge' (delete_record)`), on the traversal #5383/#5635 added to this family.
+
+  Deliberately out of range: an empty **combinator** array (`{ $and: [] }`,
+  `{ $or: [] }`). #5322/#5134 ruled those and every driver implements the ruling —
+  empty `$and` is TRUE (so it _is_ a whole-object write), empty `$or` is FALSE (so
+  it matches nothing and must never be warned about) — but telling them apart
+  requires the boolean-identity reduction, which already exists producer-side in
+  each driver. A hand-written fourth copy inside a linter is how a scan and a
+  validator come to answer with two different predicates, so that case is tracked
+  separately instead.
+
+- 7f1a635: fix(lint,spec,objectql): 编写期表达式与 `highlightFields` 校验识别注册表注入的系统列 (#5378)
+
+  平台在每个业务对象上注入 `owner_id` / `created_at` / `organization_id` 等系统列,
+  文档也把 `ownership: 'user'` 写作 "injects reassignable owner_id"。但编写期的两处
+  校验只读**作者声明的** `fields`,于是注入列一律当作不存在:
+
+  - `validate-expressions.ts` 的 `buildFieldIndex` 让 `has(record.owner_id)` 直接
+    报错 `unknown field owner_id`;
+  - `highlightFields` 存在性检查对 `['owner_id']` 发出 "is not a field on this
+    object — it is silently skipped by every consumer"。
+
+  也就是平台自己的 linter 否认平台自己的契约。结果是应用被迫**重声明系统列**才能通过
+  编写期校验:hotcrm#548 为此在全部 12 个业务对象上显式声明了 `owner_id`(6 个对象曾
+  报 `highlightFields` 警告,`contact_welcome` 触发器的 `has(record.owner_id)` 被硬
+  拒)。这正是本项目视为缺陷的形状:能力已声明(列确实注入且有文档),但执行层不认。
+
+  **权威来源只有一份。** 新增纯派生 `resolveInjectedSystemColumns()`
+  (`@objectstack/spec/data`)回答"这个对象带哪些系统列",并由 registry 的
+  `applySystemFields()` **消费**它——沿用 #3786 为审计字段族确立的分工:spec 声明
+  **有哪些**列,registry 拥有**每列长什么样**。lint 通过同一派生取答案,因此编写期
+  判断与运行时注入不可能不一致(`@objectstack/lint` 的包契约是"只依赖 spec,绝不依赖
+  运行时",此前它根本无法读到权威)。两个消费面共用同一判定,不各写一份。
+
+  **并入是按对象有条件的**,不是无条件放行整张系统列名单:`ownership: 'org' | 'none'`
+  的对象没有 `owner_id`,那里的 `record.owner_id` 仍然是真错误并继续报;
+  `tenancy.enabled: false` 无 `organization_id`;`systemFields: { audit: false }` 无
+  审计四列;`systemFields: false` / `managedBy: 'better-auth'` 什么都不注入(只剩驱动
+  提供的主键 `id`)。真正拼错的字段照旧被拒,并且注入列现在也进入 "did you mean?" 候选
+  (`record.ownerid` → 提示 `owner_id`)。
+
+  被解析的注入列在诊断与补全语义上与授权字段等同;类型健全性与 null-guard 两个索引
+  **刻意**仍只读声明字段,原因写在各自注释里:列的 `type` 与可空性属于 registry 的列
+  定义,在 lint 侧另立一份就是本次要消灭的第二份副本,而 null-guard 喂的是会中断构建的
+  判定,擅自并入会让今天能构建的 stack 变红。
+
+  注入行为本身零改动:`applySystemFields` 的输出在全条件矩阵上逐列不变(新增 parity
+  pin 用实跑注入代码比对)。已显式重声明系统列的应用不受影响——重声明仍然合法,
+  examples 三个 app 的 `os validate` 输出改动前后完全一致。
+
+- 5d3ced9: fix(objectql,lint)!: a `json_schema` validation rule's `format` keyword is now ENFORCED — records that passed before can start failing (#5029)
+
+  > **⚠️ BEHAVIOUR CHANGE ON DEPLOYED DATA — READ BEFORE UPGRADING.** A `format`
+  > keyword inside a `json_schema` validation rule used to enforce **nothing**.
+  > It now enforces. If any deployed object carries such a rule, writes that
+  > succeeded on the previous version can be **rejected** after this upgrade —
+  > including writes from flows, seeds, imports and integrations, not just the UI.
+  > Nothing about the metadata changed; the runtime simply started honouring what
+  > the metadata always said. See "Before you upgrade" below.
+
+  ## What was broken
+
+  `packages/objectql/src/validation/rule-validator.ts` built its shared ajv as
+  `new Ajv({ allErrors: true, strict: false })` and stopped there. In ajv 8 the
+  `format` keyword is **not built in** — it ships in the separate `ajv-formats`
+  package — and under `strict: false` an unregistered format is not an error: ajv
+  logs one line at compile time and **drops the keyword**.
+
+  So this rule:
+
+  ```ts
+  {
+    type: 'json_schema',
+    name: 'support_config_shape',
+    field: 'support_config',
+    message: 'Support config is invalid.',
+    schema: {
+      type: 'object',
+      properties: { email: { type: 'string', format: 'email' } },
+      required: ['email'],
+    },
+  }
+  ```
+
+  compiled fine, ran on **every** write, enforced `type` and `required` — and
+  enforced **nothing at all** for `format`. `{ email: 'not-an-email' }` was
+  accepted, for every record, forever. The only signal was a stderr line at
+  compile time naming no rule and no object.
+
+  This is the #4649 / #4762 family one level in, and the partial failure is what
+  made it nasty: the rule visibly rejects a bad `type` / missing `required`
+  payload in dev, so it reads as _working_ while the `format` half never fires.
+  `format` is also one of the most reached-for JSON Schema keywords (`email`,
+  `uri`, `uuid`, `date`, `date-time`, `ipv4`), so this was not an exotic corner —
+  and it is exactly the shape an AI writing metadata reaches for first.
+
+  ## What changed
+
+  - **`@objectstack/objectql`** now depends on `ajv-formats` and registers it on
+    the shared instance (`addFormats(ajv)`). The **default (full)** format set is
+    used deliberately: `fast` mode trades correctness for speed on precisely the
+    formats authors reach for most, and a format that "mostly" matches is the same
+    declared ≠ enforced defect with a smaller hole.
+  - **`@objectstack/lint`** — the #4762 publish gate
+    (`validate-rule-compilability.ts`) compiles every `json_schema` rule with the
+    SAME ajv environment the runtime uses, on purpose, so it registers the same
+    plugin. This is not cosmetic parity: `ajv-formats` also installs the
+    `formatMinimum` / `formatMaximum` keywords, so a gate without it treats them
+    as unknown keywords (`strict: false` ⇒ silently ignored) and would publish a
+    schema the runtime then refuses to compile — a rule that passes review and
+    enforces nothing, which is the failure that gate exists to prevent. The parity
+    test now reads the plugin registration out of the runtime's source, so the two
+    cannot drift apart silently.
+
+  **Authoring is unchanged.** `format` stays a legal, publishable JSON Schema
+  keyword; the publish gate does not refuse it (option 2 on #5029 was considered
+  and rejected — refusing standard JSON Schema would push authors into private
+  spellings). What changed is only that the declaration is now true.
+
+  ## Before you upgrade
+
+  1. Find the rules at risk: any `object.validations[]` entry with
+     `type: 'json_schema'` whose `schema` contains a `format` key, at any depth
+     (including inside `$defs` / `$ref` and a `conditional`'s `then` /
+     `otherwise` branch).
+  2. For each, audit the existing column against that format. Rows already stored
+     are **not** re-validated — nothing is rejected retroactively, and no
+     migration runs — but the **next write that touches the field** is checked,
+     which includes an unrelated PATCH that merely resends the JSON blob.
+  3. If a format was aspirational rather than real, remove that `format` key (or
+     relax it) _before_ upgrading. Deleting the keyword is now a meaningful,
+     visible act rather than a no-op.
+
+  ## Known limitation, recorded deliberately
+
+  A **misspelled** format name is still ignored. `format: 'emial'` compiles under
+  `strict: false` — ajv logs `unknown format "emial" ignored` and drops it — in
+  both the runtime and the publish gate, so a typo still enforces nothing. That
+  behaviour is unchanged here and pinned by test in both packages, so it is a
+  known boundary rather than an oversight; closing it is an authoring-time
+  decision of its own and is tracked separately.
+
+- 4b50be4: fix(lint): a MISSPELLED `format` in a `json_schema` validation rule is refused at publish time (#5178)
+
+  #5029 registered `ajv-formats` so a `json_schema` validation rule's `format`
+  keyword is really enforced. It did **not** close the other half, and said so:
+  under `strict: false` — which is load-bearing, because author-written schemas
+  legitimately carry vendor keywords — an **unrecognised** format name is a
+  non-event. ajv logs one line at compile time and **drops the keyword**:
+
+  ```
+  $ node -e "const Ajv=require('ajv'); const addFormats=require('ajv-formats');
+    const ajv=new Ajv({allErrors:true,strict:false}); addFormats(ajv);
+    const v=ajv.compile({type:'object',properties:{e:{type:'string',format:'emial'}}});
+    console.log('validates {e: zzz} =', v({e:'zzz'}));"
+  unknown format "emial" ignored in schema at path "#/properties/e"
+  validates {e: zzz} = true
+  ```
+
+  So an author who types `emial`, `e-mail`, `datetime` for `date-time`,
+  `urireference` for `uri-reference`, `ipv_4` for `ipv4` or `Email` for `email`
+  gets a rule that is declared, appears in the metadata, appears in every "what
+  protects this object" listing, runs on every write, enforces `type` and
+  `required` — and enforces nothing for the keyword they actually wrote. The
+  record is **accepted**, which is the silent direction: nothing in the metadata,
+  the UI or a test run says the constraint is inert. A typo is also the single
+  most likely mistake in a hand-written or AI-generated JSON Schema.
+
+  **New gate — `validateRuleSchemaFormats`**, a `gating` entry in
+  `AUTHORING_RULES`, so it runs on all three authoring commands (`os validate`,
+  `os build`, `os lint`) with no per-command wiring. One rule id:
+
+  | id                                           | fires when                                                                          |
+  | :------------------------------------------- | :---------------------------------------------------------------------------------- |
+  | `validation-rule-json-schema-unknown-format` | a `json_schema` rule's schema names a `format` the runtime's ajv has not registered |
+
+  Each finding names the rule, the object, the **RFC 6901 JSON Pointer** to the
+  offending keyword, and the **nearest registered name**:
+
+  ```
+  objects.account.validations.support_shape.schema#/properties/email/format
+    `json_schema` validation 'support_shape' on object 'account' names
+    `format: 'emial'` at `#/properties/email/format`, which is not a registered
+    format. … the schema compiles, the rule ships and runs on every write, its
+    `type`/`required` keywords are enforced, and this constraint is enforced on
+    no record, ever. The record is ACCEPTED, so nothing downstream reports the
+    gap either.
+    hint: Did you mean `format: 'email'`? The registered names are: binary, byte,
+    date, date-time, … — the default `ajv-formats` set, the one
+    `rule-validator.ts` registers (#5029).
+  ```
+
+  **The vocabulary is enumerated, never written down.** The registered set is read
+  off a live instance of the very ajv the publish gate builds to mirror the
+  runtime (`registeredFormatNames()`), not from a hardcoded list. A list would be
+  a third opinion that nobody updates: the day `ajv-formats` adds a name, it
+  starts refusing a format the write path enforces — a gate that turns working
+  metadata red gets switched off, and then protects nothing. Enumerating means the
+  gate follows the plugin across an upgrade with no edit at all.
+
+  **The walk is JSON-Schema-aware, because `format` is not a magic word.** Every
+  subschema position is visited — `properties`, `items` (both the 2020-12 schema
+  form and draft-07's tuple array), `anyOf`/`allOf`/`oneOf`/`prefixItems`,
+  `$defs`/`definitions`, `additionalProperties`, `patternProperties`,
+  `if`/`then`/`else`, `not`, `contains`, `propertyNames`, `dependentSchemas`,
+  draft-07 `dependencies` — at any depth, plus the rules nested in a
+  `conditional`'s `then`/`otherwise`. Positions that hold arbitrary **data** are
+  deliberately never read: a `format` inside `default`, `const`, `enum` or
+  `examples` enforces nothing and was never meant to, so reporting it would invent
+  a defect out of a legal document. A non-string `format` (`format: 42`) is left
+  to `validation-rule-json-schema-uncompilable`, which already refuses it in
+  ajv's own words.
+
+  **The runtime is untouched, and so is the #4762/#5029 compile parity.** Option 2
+  on #5178 (make an unknown format a runtime compile error) was rejected: it fires
+  at runtime and fail-**open**, since `checkJsonSchema` catches, logs and skips —
+  trading one silent gap for another. And this is a separate judgement laid
+  _beside_ the existing compile, never folded into it: `validateRuleCompilability`
+  still compiles each schema in the runtime's exact environment and still
+  **publishes** a typo'd format, because a typo'd format compiles there too. Its
+  `#5029` pin ("a MISSPELLED format name is published, not refused") passes
+  verbatim. Two questions, two rules — "does ajv accept this schema?" and "will
+  this `format` keyword do anything?" — sharing one traversal and one ajv
+  environment so they can never disagree about which rules exist or what
+  "registered" means.
+
+  `ajv` / `ajv-formats` stay **lazy**, and this rule is lazier than its neighbour:
+  the registered vocabulary is only fetched once a schema actually names a
+  `format`, so a `json_schema` rule that names none loads neither package. Pinned
+  by the package's `lazy-deps.test.ts` in all three of its layers.
+
+  **Upgrading:** if `os validate` / `os build` / `os lint` newly rejects a
+  `json_schema` validation rule, the format name in it was never being enforced —
+  fix the spelling to the name the finding suggests, or express the constraint
+  with `pattern`, which is enforced. No metadata that was working changes
+  behaviour.
+
+- 461ccda: fix(lint): 收敛 `validateStackExpressions` / `validateSecurityPosture` 里读 spec 不声明键的 `??` 别名链 (#5017)
+
+  两条规则都以 `input: 'parsed'` 注册,看到的是 `ObjectStackSchema` 解析后的产物。
+  #4984 → #5009 清掉了 sharing rule 字段层和 org-axis 规则里的同形读法;这一轮是同族
+  第三轮,落在另外两个文件。议题点名五条,全包 grep 又找出同形的两条,一并处置:
+
+  | 原读法                                                                      | spec 事实                                                                                           | 处置                           |
+  | :-------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------- | :----------------------------- |
+  | `rule.expression ?? rule.predicate ?? rule.condition ?? rule.formula`(两处) | 四个别名全是 `validation.zod.ts` 的 `aliases: { …: 'condition' }` **按名拒绝**的键;canonical 排第三 | 收敛为 `rule.condition`        |
+  | `obj.validations ?? obj.validationRules`                                    | `ObjectSchema` 只声明 `validations`,strict 按名拒绝                                                 | 收敛为 `obj.validations`       |
+  | `rule.condition ?? rule.criteria ?? rule.predicate`                         | `criteria` 是运行时编译产物 `criteria_json` 的拼法(#3896),`predicate` 直接拒绝                      | 收敛为 `sharingRule.condition` |
+  | `def.reference ?? def.referenceTo`                                          | `field.zod.ts:331` 把 `referenceTo` 映射为 `reference`                                              | 收敛为 `def.reference`         |
+  | `action.objectName ?? action.object`                                        | canonical 是 `objectName`;`object` 按名拒绝                                                         | 收敛为 `action.objectName`     |
+  | `obj.sharingModel ?? (obj.security)?.sharingModel`                          | **`ObjectSchema` 根本没有 `security` 键** —— OWD 三个拨盘是平铺的,且 strict:嵌套写法被整包拒绝      | **删除整个 fallback**          |
+  | `def.reference ?? def.reference_to`                                         | 同 `referenceTo`                                                                                    | 收敛为 `def.reference`         |
+
+  对任何能解析的 stack,判定结果不变 —— 三个 example(crm / showcase / todo)与平台
+  default permission sets 上,改动前后两条规则的 findings 逐字相同。
+
+  **其中一条不是死代码,是活着的错。** `rule.expression ?? … ?? rule.condition ?? …`
+  把 canonical 的 `condition` 排在两个被拒别名之后,所以一条同时写了 `condition` 和
+  `expression` 的规则,lint 校验的是 schema 会拒绝的那个,而作者声明的那个**从头到尾
+  没被看过**:producer 和 consumer 对同一份元数据给出两套说法。测试里重建了旧链来演示
+  这个差异,而不是只描述它。
+
+  真正的代价从来不是漏报,而是误导 —— `object.security.sharingModel` 出现在**安全
+  linter**里,足以让下一位作者(人或 AI)相信对象级 `security` 信封是真实的授权面。
+
+  同时补上两层结构性 meta-guard(#4992 模式,#5018 形状),让下一条死读法在 review
+  前就红:
+
+  - **declared-key guard** —— 规则源码里从每个 surface 上读的键,必须出现在该 surface
+    自己的 Zod `.shape` 里。扫源码不是扫行为是刻意的:不可达分支没有行为可断言。
+  - **reachability guard** —— `validateSecurityPosture` 全部 15 个 `findings.push`
+    落点都必须被一条 schema **不报 `unrecognized_keys`** 的 fixture 触达。判据不是
+    #5018 的 `safeParse` 全绿,而这正是这条规则的特点:它被文档明确设计为也跑在
+    parse 前,好让 `os lint` 对 zod 会拒绝的**值**(`sharingModel: 'read'`)给出更
+    好的信息。被拒的**值**和被拒的**键**是两回事 —— 后者在 parsed 路径上压根到不了。
+
+  七条读法各自做过变异测试:任意一条加回去,都至少有一条测试转红。
+
+- 58f3220: null-guard 闸门改走 `@objectstack/formula` 的规范解析入口,并移除对 `@marcbachmann/cel-js`
+  的直接依赖(#4812)。
+
+  `validate-null-guards.ts` 此前自建了一个**不带 limits** 的 cel-js `Environment`,于是它会解析、
+  并进而判定平台自身拒绝的谓词 —— 超过 `maxAstNodes` (256) / `maxDepth` (32) /
+  `maxListElements` (64) 的表达式在 lint 侧照常出 finding,在 `compile()` 侧却是
+  `Exceeded max…`。两个解析入口,两个答案,而这个闸门握着更宽松的那个。
+
+  改走 `parseCelToAst` 后两者合一。超界表达式不再由本闸门二次判定,而是交还给同一批调用点上
+  本就在跑的 `validateExpression` —— 它以 blocking error 报告边界错误,措辞面向自纠;作者修好
+  边界问题后,null-guard 判定自然回来。规则判定本身没有变化:#3306 的三元重写对本 pass 是
+  verdict-neutral(重写仅在三元的某一支恰为 `null` 字面量时触发,而该支本就证明不出任何
+  guard),已加测试钉住。
+
+- f238970: fix(lint): 收敛 `validateRuleCompilability` 里读 spec 不声明键的 `??` 别名链 (#5096)
+
+  #4984 → #5009 → #5017/PR #5046 同族第八处,落在第三个文件
+  (`validate-rule-compilability.ts:239`):
+
+  | 原读法                                   | spec 事实(对 live `.shape` + `safeParse` 实测)                                                                                                                                                                  | 处置                     |
+  | :--------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----------------------- |
+  | `obj.validations ?? obj.validationRules` | `ObjectSchema.shape` 只声明 `validations`,且 strict —— `validationRules` 被**按名拒绝**:`Unrecognized key(s) on this object: \`validationRules\`. … Did you mean \`validationRules\` → \`validations\`?`(#4001) | 收敛为 `obj.validations` |
+
+  该规则以 `input: 'parsed'` 注册,canonical 排首位,所以别名 limb 对任何能解析的
+  stack 都不可达 —— 三个 example(crm / showcase / todo,共 28 个对象、17 条验证规则)
+  上改动前后 findings **逐字相同**(两侧均 0 条)。
+
+  **代价从来不是漏报,而是误导。** 一个写在 consumer 里的别名 fallback,等于向后来的
+  读者、以及照着这份源码写元数据的 AI 宣称 `objects[].validationRules` 是一个真实的
+  authoring 面;它把 schema 一句指名道姓的拒绝,降级成一条静默失效的分支。别名容忍属于
+  producer 的拒绝面,不属于 consumer(Prime Directive #12)。
+
+  同时给本文件补上两层结构性 meta-guard(#4992 模式,#5017 形状),让下一条死读法在
+  review 前就红:
+
+  - **declared-key guard** —— 规则源码里从 `stack` / `obj` / `rule` 上读的每个键,必须
+    出现在对应 surface 自己的 Zod `.shape` 里,且 `expected` 精确匹配;另加一条 "covers
+    every receiver" 元测试,以及一条针对 `flattenRules` 里 `rule[branch]` **计算属性**
+    读法的专项断言(点号扫描看不见它,而 `then` / `otherwise` 恰是本规则最有意思的读法)。
+  - **reachability guard** —— 两个 `findings.push` 落点都必须被一条 `ObjectStackSchema`
+    **完整 parse 通过**的 fixture 触达。这里用的是 #5018 的 `safeParse` 全绿判据,比
+    `validate-security-posture` 只能要求"不报 `unrecognized_keys`"更严一档 —— 因为本规则
+    判的是"编译不过",而在 spec 眼里 `regex` 是任意字符串、`schema` 是任意 record,编不过
+    的产物依然完全 spec 合法:这条 gate 存在的理由正是 zod 看不见该缺陷,所以它永远不需要
+    一条 zod 会拒绝的 fixture。
+
+  原测试 `reads \`validationRules\` too` 断言的正是被删掉的那条 limb,实测确实产出 1 条
+  finding(不是空转),因此它被**替换**而不是改拼写:把 key 换成 canonical 只会留下一条
+  主题已不存在的绿测试。变异测试:别名 limb 加回去 → 2 条红;改成纯别名读 → 11 条红。
+
+- 06fc07a: `os validate` now reports a `config.timeRelative` that is not a descriptor object
+
+  A flow start node whose `config.timeRelative` held a scalar — `timeRelative: 'daily'`
+  is the natural mistake, from fusing the sweep's **cadence** with its **descriptor** —
+  was accepted in complete silence at every layer. The node `config` slot is open by
+  design (ADR-0018) so the schema parsed it; the engine routes a flow to the
+  time-relative sweep only when `config.timeRelative` is an object, so the flow fell
+  through that branch and, with no other trigger key on the node, bound to nothing and
+  never fired. Not one diagnostic was produced anywhere — not even the single bind-time
+  warn that an object-but-unparseable descriptor gets, because the trigger was never
+  handed the flow at all.
+
+  A new authoring rule, `flow-time-relative-descriptor-unroutable` (warning), reports it
+  at authoring time with the value, its type, and the consequence — and a hint that
+  separates the two fused concepts: the descriptor says WHICH records to sweep
+  (`{ object, dateField, and exactly one of withinDays | offsetDays }`), while HOW OFTEN
+  is the sibling key `config.schedule`.
+
+  Nothing is made tolerant: a scalar is still not a descriptor and the runtime's
+  behaviour is unchanged. The rule is a separate criterion from
+  `flow-time-relative-descriptor-invalid` (#5496) rather than a widening of it, and the
+  two partition the key along the engine's own routing predicate — a value the engine
+  routes gets the schema's verdict, a value it routes nowhere gets this one, and never
+  both. Arrays and `Date` are `typeof 'object'`, so they stay with the shape rule.
+
+- 61fde5e: lint: warn when a form section declares a `label` but no `name` — the heading no translation key can ever address
+
+  `_sections` is keyed by the section's `name`, and every renderer that draws a
+  section heading resolves it that way (`sectionLabel(objectName, section.name,
+authored)` — `plugin-form`'s `ObjectForm`/`ModalForm`, `plugin-detail`'s
+  `record:details`), falling back to the authored label when there is no name.
+  So a section authored with a `label` and no `name` is untranslatable **by
+  construction**, and every gate we own was structurally blind to it:
+
+  - the reference validator reports keys a bundle carries that nothing declares —
+    a nameless section produces no key, so there is no orphan to report;
+  - the i18n coverage walk (#5405) emits one expected key per `sections[].name` —
+    a section with no name contributes nothing to demand, so the report reads
+    100% while the heading renders in the source locale in every locale.
+
+  Measured on HotCRM: **70 of 70** form-view sections across all 14 view files are
+  in exactly that state, with four locales at full declared coverage and zero
+  warnings anywhere. It is also the real cause of the reported `Case / SLA /
+Resolution` English strip — that object's _detail page_ sections carry names and
+  translate, while its _form view_ sections carry none.
+
+  `validateTranslatableSections` (rule id `translation-section-name-missing`) joins
+  the reference-integrity suite, so it runs on `os validate`, `os lint` and
+  `os compile` at once. It reads exactly the anchors the two landed halves already
+  agree on: a view container's `sections`, its **default** `form.sections`, every
+  `listViews.*` / `formViews.*` sub-container, the same three on views embedded in
+  an object, and `record:details` sections nested anywhere in a page's component
+  tree. `fieldGroups`-derived sections are out of range by construction — their
+  heading is keyed by `fieldGroups[].key`, so they always have a name.
+
+  **Warning, and opt-in.** Nothing crashes and nothing is dead — one heading stays
+  in the source locale — so the severity matches its sibling rules (ADR-0072 D1)
+  and nothing that passed before starts failing. `os validate` over
+  `examples/app-showcase` now reports 14 of these (6 from form views, 8 from
+  `record:details` pages) and still exits 0. A section warns only when the
+  object it renders under carries some translation of its own, which keeps the
+  monolingual case silent exactly as the coverage gate already does.
+
+  The fix is a diagnostic at the **producer**, deliberately not tolerance at the
+  consumer: deriving a lookup key by slugifying the label would fossilize a second
+  de-facto contract next to the declared one, and would move the day anyone edits
+  the heading text. The `name` the hint suggests is a suggestion for the author to
+  write down, never a key anything resolves.
+
+- 471839d: fix(spec): classify the 22 dashboard widget keys and refuse undeclared container inheritance (#4956)
+
+  The spec liveness ledger's `dashboard.widgets` entry carried one blanket `live`
+  verdict plus a `note` asserting that the per-widget props were _"classified in
+  the DashboardWidgetSchema subtree"_. **No such subtree ever existed.** The gate's
+  walk drills one level and only through an explicit `children`, and `widgets`
+  declared none — so all 22 authorable keys of the strict `DashboardWidgetSchema`
+  were never classified, never counted as unclassified, and every run printed
+  "all governed-type properties are classified" anyway.
+
+  That gap — not evidence — is what carried `widgets[].responsive` through the
+  #3896 inert-key sweep that removed both its sibling `widgets[].performance` and
+  its literal namesake `view.responsive`. `view` is drilled through `children`, so
+  `list.responsive` got asked and went out; `widgets` was never asked. It was
+  finally retired in #4876 / PR #4995, by hand, four days late.
+
+  **What changed for authors**
+
+  The `objectstack build` / `objectstack lint` advisory now covers dashboards, so
+  five widget keys warn at build time (they never did before — `dashboard` was not
+  in the lint's type collections, because until now its ledger warned on nothing):
+
+  | Widget key               | Why it warns                                                                                                                   | What to do instead                                                                                               |
+  | :----------------------- | :----------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------- |
+  | `widgets[].colorVariant` | no render path reads the top-level key — only the authoring panels do                                                          | move it under `options` (the inline metric card reads it there); the dataset-bound path has no colour affordance |
+  | `widgets[].actionUrl`    | no renderer draws a per-widget action button; every `actionUrl` the dashboard renderer reads belongs to `header.actions[]`     | use `dashboard.header.actions[]`                                                                                 |
+  | `widgets[].actionType`   | pairs with the above                                                                                                           | as above                                                                                                         |
+  | `widgets[].actionIcon`   | zero readers in either repo                                                                                                    | as above                                                                                                         |
+  | `widgets[].aria`         | declared ARIA attributes never reach the DOM — the same false-compliance shape as the dashboard-level `aria` removed in 17.0.0 | delete it; the renderer emits its own `aria-*`                                                                   |
+
+  Advisory only — the build never fails on these. **Nothing is removed and no
+  runtime behaviour changes**: this records verdicts, it does not act on them.
+  Enforce-or-remove (ADR-0049) for the five is tracked separately.
+
+  Two verdicts worth knowing because they cut the other way: `requiresService` is
+  **live** — it reads as inert in the renderer repo but the REST layer strips
+  widgets whose service is unregistered (ADR-0057 D10) — and `compareTo` is live
+  on the inline chart path only; on the ADR-0021 dataset path the string arms are
+  dropped and `{ offset }` fails in the analytics executor.
+
+  **What changed for the gate**
+
+  `pnpm --filter @objectstack/spec check:liveness` gains a third direction. A
+  ledger entry sitting on a container property must now declare one of exactly
+  three dispositions, all of them data: **drilled** (`children`), **deferred** (a
+  `{ container, to }` row naming the coordinate that does classify the subtree),
+  or **recorded** (a row in the shrink-only
+  `scripts/liveness/undrilled-containers.baseline.json`). A container in none of
+  the three fails, and so does a baseline row whose container has since been
+  drilled.
+
+  A deferral is **resolved, not believed** — the target must exist (a governed
+  type root, or a drilled `type/prop` coordinate) and classify exactly the
+  container's child keys; a dangling or drifted target fails. That is the #4956
+  claim itself, made checkable: pointing a deferral at `DashboardWidgetSchema`
+  now produces a build failure naming it, where the same words in a `note` were
+  believed for a release.
+
+  Every run reports both populations (today: 58 containers / 292 child keys
+  classified nowhere, plus 6 resolved deferrals covering 248), `--undrilled`
+  prints the worklist, and the success line no longer claims a completeness it
+  does not have.
+
+- b821b29: fix(lint): 清除 `validateOrgAxisRedLines` 里 spec 合法 stack 永远到不了的四条分支 (#5009)
+
+  `validate-org-axis-red-lines.ts` 是 `input: 'parsed'` 规则 —— 它看到的是
+  `ObjectStackSchema` 解析后的产物。#4984 修掉了 sharing rule 字段那一层的 `??`
+  别名读法,但同一文件里还留着四条同形分支,每一条读的键 spec 都不声明:
+
+  | 原读法                                                          | spec 事实                                                                                                                                              | 处置                      |
+  | :-------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------ |
+  | `cfg.permissions ?? cfg.permissionSets`                         | stack 根 **strip** 未声明键,`permissionSets` 解析后必为 `undefined`                                                                                    | 收敛为 `cfg.permissions`  |
+  | `cfg.sharingRules ?? cfg.sharing`(两处)                         | 同上                                                                                                                                                   | 收敛为 `cfg.sharingRules` |
+  | `str(rule.object ?? rule.objectName)`                           | `SharingRuleSchema` 是 `.strict()`,按名拒绝 `objectName`;`object` 又是必填                                                                             | 收敛为 `rule.object`      |
+  | `asArray(object.rowLevelSecurity ?? object.rls)` 整段(约 20 行) | **`ObjectSchema` 两个键都不声明**,且 `.strict()` —— 带对象级 RLS 的 stack 在 `os validate` / `os build` 直接被拒("Unrecognized key(s) on this object") | **删除**                  |
+
+  对任何 spec 合法的 stack,判定结果不变:这些分支本来就永远不执行(反向验证 ——
+  新测试跑在改动前的实现上,29 条由 `safeParse` fixture 驱动的断言全绿)。真正的
+  代价从来不是漏报,而是误导:对象级 RLS **根本不是授权面**(`authorable-surface.json`
+  里只有 `security/PermissionSet:rowLevelSecurity` 一条),而那段死代码连
+  `objects[N].rowLevelSecurity[M].using` 的诊断 path 都写好了,足以让下一位作者
+  (人或 AI)相信它是真的并照着写更多代码 —— #5008 差点就这么做了。
+
+  行为上唯一的差别落在 `os lint`(不 parse,跑 normalized 层):把别名拼法写进
+  stack 的作者,不再从这条红线拿到诊断,而是从 schema 那里拿到一条指名道姓的
+  拒绝。别名容忍属于 producer 的拒绝,不属于 consumer(Prime Directive #12)。
+
+  同时补上一层结构性 meta-guard(#4992 模式),让下一条死分支在 review 前就红:
+
+  - **declared-key guard** —— 规则源码里从 stack / permission set / RLS policy /
+    object / sharing rule 上读的每一个键,都必须出现在对应 schema 自己的 `.shape`
+    里。扫源码而不是扫行为是刻意的:不可达分支根本没有行为可断言。
+  - **reachability guard** —— 每个 `findings.push` 调用点都必须被至少一条过
+    `safeParse` 的 fixture 触达;走不到的分支不允许存在。
+  - 规则 ① 的 fixture 现在也走 `PermissionSetSchema.safeParse`(此前只有 sharing
+    rule 和 object fixture 有这层保护)。
+
+  四条分支各自被变异测试验证过:把任意一条加回去,都至少有两条测试转红。
+
+- da1a64c: fix(lint): reject a validation rule whose regex or JSON Schema does not compile, at authoring time (#4762)
+
+  Two of the six object validation-rule types carry a **static artifact** that the
+  write path hands to a real compiler, inside a `try/catch` that logs and returns
+  `null`:
+
+  - `format` → `new RegExp(rule.regex)` → _"Validation rule '…' has an invalid regex — skipped"_
+  - `json_schema` → `ajv.compile(rule.schema)` → _"Validation rule '…' has an uncompilable JSON Schema — skipped"_
+
+  "Skipped" means the rule is declared, appears in the metadata, appears in every
+  "what protects this object" listing — and enforces nothing, on every record, for
+  as long as the metadata is deployed, with a WARN line in a log nobody reads as
+  the only signal. That is the shape #4649 was filed about one rule type over;
+  #4761 flipped the CEL predicates to fail closed and deliberately left these two,
+  because their blast radius differs (see below).
+
+  **New gate — `validateRuleCompilability`**, a `gating` entry in
+  `AUTHORING_RULES`, so it runs on all three authoring commands (`os validate`,
+  `os build`, `os lint`) with no per-command wiring. Two rule ids:
+
+  | id                                         | fires when                                                   |
+  | :----------------------------------------- | :----------------------------------------------------------- |
+  | `validation-rule-regex-uncompilable`       | a `format` rule's `regex` throws in `new RegExp(...)`        |
+  | `validation-rule-json-schema-uncompilable` | a `json_schema` rule's `schema` throws in `ajv.compile(...)` |
+
+  Each finding names the rule, the object and the config path, and carries the
+  **compiler's own error text verbatim** — an author cannot act on "invalid
+  regex", but can act on `Invalid regular expression: /([/: Unterminated character
+class`. Rules nested in a `conditional`'s `then` / `otherwise` are judged too
+  (`evaluateRule` recurses into them and reaches the very same checkers), and the
+  finding names the branch it is in.
+
+  **Detection is the real compilers, never a pattern that judges a pattern.** The
+  regex is compiled with `new RegExp(source)` — the exact call `checkFormat`
+  makes. The schema is compiled with ajv constructed with the **same options the
+  runtime's shared instance uses** (`{ allErrors: true, strict: false }`), read
+  back out of `rule-validator.ts`'s source by a parity test so the day those
+  options change, this gate is told rather than left quietly disagreeing.
+  `strict: false` is load-bearing in both directions: a gate running `strict: true`
+  would reject author-written schemas carrying vendor keywords that the write path
+  compiles happily — a gate that turns working metadata red gets switched off, and
+  then protects nothing.
+
+  `ajv` is a new dependency of `@objectstack/lint`, loaded **lazily**: only a
+  stack that actually declares a `json_schema` validation rule pays for it, pinned
+  by the package's `lazy-deps.test.ts` alongside `typescript` and `sucrase`. The
+  kernel boot path (`@objectstack/lint/runtime`) never loads it at all.
+
+  **The runtime half is deliberately unchanged.** `rule-validator.ts` still fails
+  open on both, and the `#4649 — unchanged neighbours` pins that record it stand
+  exactly as they are. A broken regex or schema is _static_ — decidable from the
+  metadata alone, with no record in hand — so the authoring door closes the class
+  outright without ever bricking a running deployment, whereas rejecting at write
+  time would reject **every** write touching that field for as long as the bad
+  metadata is deployed. Whether a runtime backstop is still wanted on top of a
+  closed authoring door stays open on #4762.
+
+- 5e3c83b: fix(lint): 七个规则 id 常量补进 barrel —— 消费者不必再对字面量,并加一条测试面门禁 (#5648)
+
+  规则把自己的 id 写进每条 finding 的 `f.rule`,而那个字符串就是 `os lint --json` / `os validate` 递到消费者手上的东西:Studio 的 finding 渲染、下游按规则过滤/抑制、以及被授权元数据里的 `suppressWarnings: ['<rule-id>']`。规则文件为此导出同名常量,消费者本该比对常量而不是重敲 slug。
+
+  但 `packages/lint` 的 `package.json#exports` 只开 `"."` 与 `"./runtime"`(`tsup.config.ts` 的 entry 也只有这两个),所以**没进 barrel 就不是「不好取」,而是完全取不到** —— 没有深路径可绕,消费者唯一的退路正是那个常量本来要消灭的字符串字面量。
+
+  #5648 报的是其中一个(`FLOW_TRIGGER_UNKNOWN_EVENT`,#3427/#3457/#3481 三条规则共用的 id)。它要求的全量清查又翻出**六个**,散在五个规则文件、成因都远早于它:`APPROVAL_APPROVER_TYPE_UNSUPPORTED`、`SECURITY_FLS_UNQUALIFIED_KEY`、`FIELD_GROUP_SHADOWED`、`WIDGET_LEGACY_ANALYTICS_SHAPE`、`WIDGET_LEGACY_ANALYTICS_UNRENDERABLE`、`REACT_CHART_DRILLDOWN_INVALID`。其中 `WIDGET_LEGACY_ANALYTICS_SHAPE` 最能说明代价:规则打给用户的提示原话就是 `Suppress with suppressWarnings: ['widget-legacy-analytics-shape']`,即它主动教消费者用这个 id,却不让消费者拿到承载它的常量。
+
+  漏项之所以能一路静默:规则照常工作,它自己的单测**从规则文件直接 import 常量**(不经 barrel),于是唯一会发现的时刻是有人从包外去消费它。同一种一行漏项独立发生七次,不是「下次记牢」能解决的记性问题,而是缺一条判定。
+
+  **因此判定权移进 `packages/lint` 测试面**(`src/rule-id-barrel-exports.test.ts`):新增规则时忘了 barrel 那行,会在新规则自己的测试转绿的同一次 run 里失败。分层理由是这条不变量完全是包内的 —— 没有别处定义 lint 规则 id —— 且它要**真的 import** barrel 来核验取值,vitest 天然给得到;换成 `scripts/` 门禁则要么自己写一个 ES 解析器,要么先构建 dist,还会把反馈挪到另一个 job。
+
+  门禁按两类假绿反向设计:发现面是对 `src/` 的**文件系统读取**而非手写清单(新规则文件一存在即被枚举),并对 id 条数压一条下限,避免将来改坏提取式后在空集上「全绿」;两个 entry 虽是静态列出(全动态 import 无法可靠打包),但另有一条用例从 `package.json#exports` 与 `tsup.config.ts` **各自独立**推导出同一集合并比对,新增第三个 entry 若不登记就会红,而不是悄悄不被检查。
+
+  分类按**取值形状**而非发射位置判定:早先一版靠「定义旁边有 `rule: NAME`」来认,结果漏掉了经辅助函数参数发射的四个 `REACT_CHART_*` —— 恰好包含本次真实漏项之一。
+
+  仅新增导出面,无行为变化:任何既有 `f.rule` 字符串都没有改动,原先对字面量的消费者继续可用。
+
+- 20963e7: fix(lint): `translation-target-unknown` reads a view container's DEFAULT `form.sections` (#5415)
+
+  `validate-translation-references` derives the `_sections` names an object may
+  legally be translated by from a list of anchors: `fieldGroups[].key`, the named
+  sections on `listViews.*` / `formViews.*`, the named sections on a page's
+  `record:details` component, and the view record's own `sections`. The list was
+  missing one: the view CONTAINER's **default form** — the `form` that
+  `defineView({ list, form, formViews })` declares and that `ObjectForm` renders
+  when no named form view is asked for.
+
+  `collectViewRecord` iterated `['listViews', 'formViews']`, and `view.form` is
+  neither of those nor the record's own `sections`, so `view.form.sections[].name`
+  contributed **nothing** to the fact set. The renderer resolves those headings
+  through exactly the same `sectionLabel(object, section.name, …)` convention as
+  any named form view, so a bundle that correctly translated one of them was
+  reported as keyed to a section "which nothing on object X declares", with a hint
+  advising the author to delete a translation that renders. On the in-repo
+  showcase contact surface — whose object declares `field.group` and no
+  `fieldGroups[]`, so the default form is its **only** section anchor — all four
+  headings were in that state, and the hint went as far as "declares no named
+  section at all".
+
+  The default form now feeds the same section collector as `formViews.*`, bound
+  by `bindingOf(view.form) ?? listBinding` — i.e. `form.data.object` first, then
+  the record-level object, then the list beside it — which is the resolution the
+  CLI i18n walker performs for the same surface, so the rule that DEMANDS a key
+  and the rule that ACCEPTS one agree on which object a heading belongs to. Each
+  anchor is now a call into one collector rather than its own copy of the loop.
+
+  Nothing tightens: an unnamed section is still untranslatable (it has no stable
+  key to look up), and a `_sections` key no anchor declares is still reported —
+  now with the real anchors enumerated in the hint.
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [0f17114]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [58f3220]
+- Updated dependencies [07f1822]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [d9971d3]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [bf1edef]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/formula@17.0.0-rc.4
+  - @objectstack/sdui-parser@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Minor Changes
diff --git a/packages/lint/package.json b/packages/lint/package.json
index 33c8445a2d..d28032e650 100644
--- a/packages/lint/package.json
+++ b/packages/lint/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/lint",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "Static, build-time validation for an ObjectStack metadata graph — dashboard widget bindings, CEL/predicate expressions, and more. Pure (stack) => Issue[] functions shared by the CLI's `os validate` and any other consumer (e.g. AI authoring). Depends on @objectstack/spec; never on a runtime.",
   "type": "module",
diff --git a/packages/mcp/CHANGELOG.md b/packages/mcp/CHANGELOG.md
index 94dbf52b95..709e8ae5f0 100644
--- a/packages/mcp/CHANGELOG.md
+++ b/packages/mcp/CHANGELOG.md
@@ -1,5 +1,179 @@
 # @objectstack/plugin-mcp-server
 
+## 17.0.0-rc.4
+
+### Minor Changes
+
+- ae490ef: feat(mcp): 开源发行版终于消费 skill —— `instructions` 半边投影为 MCP `prompts` 原语 (#3905)
+
+  `stack.zod.ts` 与 ADR-0063 §2 把 **skill 定为唯一第三方扩展原语**,而开源发行版
+  (BYO-AI,cloud ADR-0025)里零消费方:`SkillSchema` 可作者化、被两条 lint 规则认真
+  校验(`validateAiToolReferences` / `validateAiSurfaceAffinity`),却没有任何代码路径
+  读它 —— 作者写 skill → 校验通过 → lint 通过 → **永不运行且无人告知**。这正是本仓
+  ratchet 存在的意义所要消灭的 declared ≠ enforced 形状。
+
+  **skill 的两个半边,现在各自说清楚跑在哪。**
+
+  - **`instructions`(判断力)→ MCP `prompts` 原语,处处可用。** MCP 服务器补齐了
+    `prompts/list` / `prompts/get`:每个带 `instructions` 的已注册 skill 成为一个
+    MCP 客户端可以列出并取回的 prompt(prompt 名 = skill 机器名,`label` → `title`,
+    `description` 原样带上)。HTTP 与 stdio 两条传输都服务它。
+  - **`tools` / `surface` / `triggerConditions`(接线)→ 明确标注 cloud-runtime-only。**
+    绑工具与激活判定是 in-product agent 循环的属性;MCP 里模型在客户端、服务端只有
+    一张扁平工具表,AI 暴露的 Action 早已通过 `list_actions` / `run_action` 可达。
+    文档与 schema JSDoc 如实写明,不再装样子 —— 但两半边在两个发行版里都照旧接受
+    **校验**,所以开源里写的 skill 到 cloud 上语义完整,不必写两遍。
+
+  **协议合规。** `prompts` 能力按规范声明:只有当宿主能读到本环境的 skill 元数据时
+  才声明并注册处理器(能力协商如实,与 action 工具同一套优雅降级);无 skill 时
+  `prompts/list` 返回**空列表而非报错**;`prompts/get` 取不存在的名字返回
+  `-32602 InvalidParams`;没有 `instructions` 的 skill 与 `active: false` 的 skill
+  不投影。HTTP 面的投影从**本请求自己的 bridge** 读(与 `describeObject` 同一条
+  per-environment 通道),多租户宿主不会把一个环境的 skill 服务给另一个环境。
+
+  **同时修掉同仓重名。** `packages/mcp/src/skill.ts` 从来不是 skill 元数据类型,
+  而是 ADR-0036 Amendment C 的 `SKILL.md` 分发物 —— 在 `packages/mcp` 里 grep
+  `skill` 先找到的一直是它。现在按各自承载的产物命名:`skill-md.ts`(SKILL.md
+  分发物)与 `skill-prompts.ts`(skill 元数据 → prompts 投影),两侧模块头互指。
+  包的公开导出名(`renderSkillMarkdown` / `OBJECTSTACK_SKILL_NAME` /
+  `OBJECTSTACK_SKILL_DESCRIPTION` / `RenderSkillOptions`)一个未变。
+
+### Patch Changes
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [64cd010]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [b746aa0]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [0f17114]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [58f3220]
+- Updated dependencies [07f1822]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [08f93bc]
+- Updated dependencies [d9971d3]
+- Updated dependencies [eb3e650]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [02dc076]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [46365ab]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [c5adfe1]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [bf1edef]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/types@17.0.0-rc.4
+  - @objectstack/core@17.0.0-rc.4
+  - @objectstack/formula@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Patch Changes
diff --git a/packages/mcp/package.json b/packages/mcp/package.json
index 06ef7323af..48beefd634 100644
--- a/packages/mcp/package.json
+++ b/packages/mcp/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/mcp",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "ObjectStack as an MCP server — exposes your app's objects (and AI tools) over the Model Context Protocol (stdio + Streamable HTTP)",
   "type": "module",
diff --git a/packages/metadata-core/CHANGELOG.md b/packages/metadata-core/CHANGELOG.md
index 279d9c4cfa..53cdcde7d5 100644
--- a/packages/metadata-core/CHANGELOG.md
+++ b/packages/metadata-core/CHANGELOG.md
@@ -1,5 +1,282 @@
 # @objectstack/metadata-core
 
+## 17.0.0-rc.4
+
+### Patch Changes
+
+- db0d53c: `resolveEngineDeleteDispatch` 末尾改真值测试:假值标量 `where.id` 不再答 `by-id`
+
+  `engine-delete-dispatch.ts` 的自我描述是「what does `ObjectQLEngine.delete` do with this call」的**唯一**答案,其测试文件头把赌注写得很明白:一份漂移的共享判定比没有判定更糟——每个钉在它上面的假引擎都会自信地、一致地错,而门禁照样报绿。这条性质此前在**假值标量 id** 上不成立,实测(origin/main,记录型 driver 驱动真实引擎):
+
+  | 调用                                 | 真实 `ObjectQL.delete` | 判定(修改前) |
+  | :----------------------------------- | :--------------------- | :----------- |
+  | `{ where: { id: 0 } }`               | `reject`               | `by-id`      |
+  | `{ where: { id: '' } }`              | `reject`               | `by-id`      |
+  | `{ where: { id: 0 }, multi: true }`  | `multi`                | `by-id`      |
+  | `{ where: { id: '' }, multi: true }` | `multi`                | `by-id`      |
+
+  原因是两侧问了不同的问题:判定读 `scalarDeleteId(...) !== undefined`,而 `engine.ts` 把判定结果落进 `id` 之后按 `if (hookContext.input.id)` 分支——**真值**测试,`0` / `''` 落到 multi/reject 阶梯。于是按 `assertEngineDeleteDispatch(options)` 钉死的替身会**接受** `delete(o, { where: { id: '' } })`,而真服务器抛 `Delete requires an ID or options.multi=true`:pinned 替身在这一个输入上仍比生产者宽松,正是本模块存在的理由(#4434 形状)。`id: ''`(路径段为空 / 表单字段未填直传 `where.id`)是可达形状,不是猎奇。
+
+  本次改的是**判定,不是引擎**。`resolveEngineDeleteDispatch` 是对 `ObjectQL.delete` 的描述,错的是描述:`delete(o, { where: { id: 0 } })` 改动前抛错,改动后照样抛错,**生产者行为零变化**,`engine.ts` 一字未动。反向做法(让 `{ id: 0 }` 变成真的按 id 删)是改生产者行为,已作为 #5747 的 B 方案明确不取。
+
+  同时给 `ENGINE_DELETE_DISPATCH_CASES` 补上 `{ id: 0 }` / `{ id: '' }` 的有/无 `multi` 四例——此前这套逐例对照**结构上够不到**这个输入(#4868 家族:一次逐例跑不可能反驳一个没人列出来的输入),这才是判定能悄悄漂移一年的原因。`scalarDeleteId` 保持值忠实(`{ where: { id: 0 } }` 仍返回 `0`),真值测试只加在判定这一层,与 update 侧孪生模块 `scalarUpdateId` 的分法一致。
+
+- 72c3c86: refactor(spec)!: retire `indexes[].type` and `indexes[].partial` — two authorable index keys no driver ever read (#5248, #4943)
+
+  `IndexSchema` declared five keys; only three of them ever reached a `CREATE
+INDEX`. `SqlDriver.syncDeclaredIndexes` builds every declared index through
+  knex's `table.index(fields, name)` / `table.unique(fields, { indexName })`, and
+  the drift differ's `DeclaredIndexInput` carries `name` / `fields` / `unique` /
+  `nullSafeColumns`. So:
+
+  - **`partial`** — documented as _"Partial index condition (SQL WHERE clause)"_ —
+    produced a **full** index with the predicate silently discarded. This was the
+    damaging half, because it reads as a correctness control: the platform's own
+    `sys_metadata` declared `partial: "state = 'active'"` for overlay uniqueness,
+    and what the declaration alone materialized was an _unrestricted_ unique index.
+  - **`type`** additionally carried `.default('btree')`, so it appeared in **every**
+    parse output of **every** index — an access-method knob that had never
+    influenced a single statement, rendered as live configuration. (It was pinned
+    as such in a `sys_presence` test, on an object that never declared it.)
+
+  Both are the ADR-0078 no-silently-inert / ADR-0049 enforce-or-remove shape.
+  Remove was chosen over enforce: enforcing needs per-dialect algorithm mapping
+  (`gin`/`gist` Postgres-only, `fulltext` MySQL-family), raw-SQL `CREATE INDEX …
+WHERE` on the dialects that have partial indexes at all (MySQL does not), and a
+  redesign of how `isSyncReproducibleIndex` excludes partial indexes from
+  incremental sync — design cost for a capability with no demand. If a real need
+  appears it returns enforce-first.
+
+  ## Migration
+
+  | FROM                                                      | TO                                                                                              |
+  | :-------------------------------------------------------- | :---------------------------------------------------------------------------------------------- |
+  | `indexes: [{ fields: […], type: 'gin' }]`                 | `indexes: [{ fields: […] }]` — create the specialised index from a database-layer migration     |
+  | `indexes: [{ fields: […], partial: "state = 'active'" }]` | `indexes: [{ fields: […] }]` — issue `CREATE [UNIQUE] INDEX … WHERE …` from a runtime migration |
+
+  **One-line fix: delete the key.** Neither removal changes any DDL, because no
+  DDL ever depended on them — verified byte-for-byte against the `CREATE INDEX`
+  statements SQLite actually stores
+  (`packages/drivers/driver-sql/src/declared-index-retired-keys.test.ts`).
+
+  Both capabilities remain available where they are implementable. The index
+  method is the driver/dialect's choice. A partial index is issued as raw SQL from
+  a runtime migration — exactly what `metadata-protocol`'s `ensureOverlayIndex`
+  already does for `sys_metadata`, and what actually delivers that table's
+  active-row-scoped uniqueness today.
+
+  ⚠️ **Not affected:** driver-sql's own `partial` flag (`parseIndexDdl` /
+  `introspectIndexes` / `isSyncReproducibleIndex`). That is a boolean parsed back
+  out of the _database's own_ DDL for drift detection — the opposite direction —
+  so migration-created partial indexes stay recognized and exempt from incremental
+  sync, unchanged.
+
+  ## The retirement kit
+
+  - `retiredKey()` tombstones at `IndexSchema` (the shape is deliberately
+    `.strip()`, so a plain delete would swap one silent no-op for another): writing
+    either key is now a `tsc` error and a parse error carrying the prescription.
+    They sit at the bottom of the shape per the #5606 renderer note.
+  - **ADR-0087 D2 conversion + D3 chain step** (`object-index-type-partial-removed`,
+    `toMajor: 17`, wired into the existing step-17 chain): strips both keys from
+    `objects[]` and `objectExtensions[]`; `os migrate meta --from 16` rewrites sources
+    mechanically. A pure lossless delete — there was no effect to lose.
+  - **Producers flipped:** `sys_metadata` (`idx_sys_metadata_overlay_active`, the
+    case #4943 named) and `sys_view_definition` (`idx_sys_view_def_active`), both
+    with their comments corrected to say what is actually materialized.
+  - Published skill (`objectstack-data`), `content/docs/data-modeling/objects.mdx`,
+    liveness ledger note and generated baselines updated.
+
+- 51a587d: 两个写动词的派发判定下沉到 `@objectstack/metadata-core` —— 公共 API 零变化,一次关闭 26 条 engine-double 基线条目
+
+  `ObjectQL.delete` / `ObjectQL.update` 的三分支派发判定(`engine-delete-dispatch.ts` #4550、
+  `engine-update-dispatch.ts` #5480)从 `packages/objectql/src/` **原样搬到**
+  `packages/metadata-core/src/`。这是一次搬移,不是重构:两个模块本来就零 import、纯自包含,
+  判定逻辑一个字未改。
+
+  **为什么搬。** `@objectstack/objectql` 的 `dependencies` 含 `@objectstack/metadata-protocol`,
+  所以那个包里 13 个假引擎结构性地无法 import 这两个谓词 —— 反向 devDependency 即成环,
+  turbo 2.10.7 直接拒绝任务图。判据来自门禁台账里
+  `packages/spec/src/contracts/data-engine.test.ts` 那条 EXEMPT:反向 import 不可行时,唯一
+  出路是下沉到**两边都已依赖**的包。`@objectstack/metadata-core` 正是这个包
+  (`objectql -> metadata-core` 与 `metadata-protocol -> metadata-core` 都是既有边),而它自己
+  的 `dependencies` 只有 `{ @objectstack/spec, zod }`,不含 objectql,故不引入新环。
+
+  **公共 API 与既有调用点零变化。** `packages/objectql/src/engine-delete-dispatch.ts` /
+  `engine-update-dispatch.ts` 保留在原路径,改为 re-export shim,因此
+  `@objectstack/objectql` 仍然导出
+  `resolveEngineDeleteDispatch` / `assertEngineDeleteDispatch` / `scalarDeleteId` /
+  `ENGINE_DELETE_REJECT_MESSAGE` / `ENGINE_DELETE_DISPATCH_CASES` 及 update 侧的五个同名对应物
+  (与全部类型),`engine.ts` 与 37 个既有 pinned 调用点一行未动。同一批符号现在也从
+  `@objectstack/metadata-core` 导出。
+
+  搭配的门禁改动:`scripts/check-engine-double-contract.mjs` 的两个 slice 现在同时接受
+  `@objectstack/metadata-core` 与 `@objectstack/objectql` 两种拼写(它们指向同一个函数),
+  失败提示也改为在「objectql 依赖该包」时优先建议 metadata-core。
+
+- 946a131: fix(metadata-core,objectql): `ObjectQL.update` 的 `data.id` 同过标量测试,不再把载荷里的算子对象当主键 (#5748)
+
+  `ObjectQL.update(object, data, options)` 用两处取主键,而这两处此前用的是**两套规则**:
+
+  - `options.where.id` 走**标量测试** —— `{ id: { $in: [...] } }` / `{ id: [...] }` /
+    `{ id: null }` 是多行谓词,不算 id(#4434 / #4550);
+  - `data.id` **不做任何测试**,只要为真就原样当主键,并且先于 `where`、也先于
+    `options.multi`。
+
+  于是同一个算子对象,写在 `where.id` 里被正确识别为谓词,写在 `data.id` 里却被
+  当成主键绑进 `driver.update(object, id, …)` 的主键位置,**显式声明的
+  `multi: true` 被无声忽略**。后果不是数据被覆盖,而是静默失灵或难读的驱动错误:
+  SQLite 侧报参数绑定错误,别的驱动可能只匹配零行 —— 两种都不会告诉调用方
+  「你的 `multi` 被忽略了」。这是 declared ≠ enforced 的一种,#5393 刚给 flow 的
+  `update_record` 补上的 `multi` 批量意图键正是被这条更早的规则盖掉的。
+
+  现在 `data.id` 与 `where.id` **共用同一个标量测试**(判定在
+  `packages/metadata-core/src/engine-update-dispatch.ts` 定义一次,`engine.ts` 与
+  全部 fake engine 经 `resolveEngineUpdateDispatch` /
+  `assertEngineUpdateDispatch` 复用同一份)。非标量 `data.id` 不算 id,因此不再
+  盖住任何东西:判定按 `where.id` → `multi` → `reject` 的原有阶梯继续往下走。
+
+  **行为矩阵(FROM → TO)。标量 `data.id` 的按 id 写法完全不受影响。**
+
+  | 调用                                                                | FROM                       | TO                                                                |
+  | :------------------------------------------------------------------ | :------------------------- | :---------------------------------------------------------------- |
+  | `update(o, { id: 'rec_1', …f })`                                    | by-id `'rec_1'`            | **不变**                                                          |
+  | `update(o, { id: 'rec_1', …f }, { multi: true })`                   | by-id `'rec_1'`            | **不变**(标量 `data.id` 仍先于 `multi`)                           |
+  | `update(o, { id: 'rec_1', …f }, { where: { id: 'rec_2' } })`        | by-id `'rec_1'`            | **不变**(标量 `data.id` 仍先于 `where`)                           |
+  | `update(o, { id: 0, …f }, { multi: true })`                         | multi                      | **不变**(真值判定,`0` 不标识行)                                   |
+  | `update(o, { id: { $in: [...] }, …f }, { multi: true })`            | by-id,算子对象被绑进主键位 | **multi** —— 声明的批量意图被执行                                 |
+  | `update(o, { id: ['a','b'], …f }, { multi: true })`                 | by-id,数组被绑进主键位     | **multi**                                                         |
+  | `update(o, { id: { $in: [...] }, …f })`(**无** `multi`)             | by-id,算子对象被绑进主键位 | **reject**,消息不变:`Update requires an ID or options.multi=true` |
+  | `update(o, { id: { $in: [...] }, …f }, { multi: false })`           | 同上                       | **reject**                                                        |
+  | `update(o, { id: { $in: [...] }, …f }, { where: { id: 'rec_1' } })` | by-id,绑的是**算子对象**   | by-id,绑的是 **`'rec_1'`**                                        |
+
+  最后一格是这次修复里唯一「判定不变、绑定值变了」的一格 —— 前后都是 `by-id`,
+  变的是哪一个 id 源胜出。`ENGINE_UPDATE_DISPATCH_CASES` 因此新增可选的
+  `expectId`,把落进主键位的值本身也钉住,避免用例因为「什么都没产出」而绿。
+
+  **「无 `multi` 的非标量 `data.id`」被明确定成响亮拒绝**,不会静默升级成一次真的
+  批量写 —— 这是裁决(维护者 2026-08-06)对方案 B 那条顾虑的处置:把算子对象写进
+  载荷大概率是写错了位置,那就报错,而不是替作者决定他想批量写。
+
+  无 API 变更:导出符号、类型与 `ENGINE_UPDATE_REJECT_MESSAGE` 的文案均不变。
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [d9971d3]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Major Changes
diff --git a/packages/metadata-core/package.json b/packages/metadata-core/package.json
index 2d2c0a8944..f6ee87cd79 100644
--- a/packages/metadata-core/package.json
+++ b/packages/metadata-core/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/metadata-core",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "Metadata Repository contracts: types, canonicalization, errors, interface (ADR-0008).",
   "type": "module",
diff --git a/packages/metadata-fs/CHANGELOG.md b/packages/metadata-fs/CHANGELOG.md
index 93388e8ba0..afab6c44e5 100644
--- a/packages/metadata-fs/CHANGELOG.md
+++ b/packages/metadata-fs/CHANGELOG.md
@@ -1,5 +1,15 @@
 # @objectstack/metadata-fs
 
+## 17.0.0-rc.4
+
+### Patch Changes
+
+- Updated dependencies [db0d53c]
+- Updated dependencies [72c3c86]
+- Updated dependencies [51a587d]
+- Updated dependencies [946a131]
+  - @objectstack/metadata-core@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Patch Changes
diff --git a/packages/metadata-fs/package.json b/packages/metadata-fs/package.json
index 7639b3211f..be16df195d 100644
--- a/packages/metadata-fs/package.json
+++ b/packages/metadata-fs/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/metadata-fs",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "FileSystemRepository: Node-only Repository implementation backed by JSON files and a JSONL change log (ADR-0008).",
   "type": "module",
diff --git a/packages/metadata-protocol/CHANGELOG.md b/packages/metadata-protocol/CHANGELOG.md
index 3876c19cf6..92b0371d81 100644
--- a/packages/metadata-protocol/CHANGELOG.md
+++ b/packages/metadata-protocol/CHANGELOG.md
@@ -1,5 +1,1409 @@
 # @objectstack/metadata-protocol
 
+## 17.0.0-rc.4
+
+### Major Changes
+
+- f61c8cf: feat(spec,metadata-protocol)!: a sort node spelling its direction `direction` is a 400, not a silently reversed page (#4721)
+
+  **FROM → TO:** `orderBy: [{ field: 'updated_at', direction: 'desc' }]` →
+  `orderBy: [{ field: 'updated_at', order: 'desc' }]`. One word. If you are on the
+  `{field, direction}` shape because you moved code over from
+  `IReportService.orderBy`, that contract is unchanged — it is `orderBy` on the
+  QueryAST / `EngineQueryOptions` axis that has always been `{field, order}`.
+
+  ## What was wrong
+
+  `SortNodeSchema` was a plain `z.object`, so zod's default `.strip` applied.
+  Measured on `main` before this change:
+
+  ```
+  SortNodeSchema.parse({ field: 'updated_at', direction: 'desc' })
+    →  { field: 'updated_at', order: 'asc' }
+  ```
+
+  `direction` was discarded and `order` fell back to its `asc` default. The sort
+  therefore ran in the **opposite** direction and the request succeeded. Paired
+  with `limit` — which is how a caller asks for "the latest N" — that is not a
+  reordered page but a **different set of rows**, returned under an ordinary 200
+  with nothing in the response to distinguish it from the answer that was asked
+  for.
+
+  `direction` is not a typo. It is the live vocabulary of a neighbouring contract,
+  `IReportService.orderBy` (`@objectstack/spec/contracts`), and
+  `plugin-auth/objectql-adapter.ts` already translates between the two by hand — a
+  translation known to be necessary and enforced nowhere, which is the ADR-0049
+  shape.
+
+  ## What changed
+
+  Both doors onto that shape, in one change:
+
+  1. **`SortNodeSchema`** (`spec/src/data/query.zod.ts`) is now `strictObject`
+     with `aliases: { direction: 'order' }`. An unknown key is rejected, and
+     `direction` specifically gets the translation in the error message — edit
+     distance can never bridge `direction` → `order`, so a bare "unrecognized key"
+     would leave the caller exactly where the silent strip did.
+  2. **`normalizeSortNodes`** (`metadata-protocol/src/protocol.ts`), the ingress
+     every REST/RPC `orderBy` funnels through, refuses `{ field, direction }` with
+     `400 INVALID_SORT` naming `order` and quoting the corrected node. Closing only
+     the schema would repeat the door asymmetry of #1535/#4522: `SortNodeSchema` is
+     reachable by three paths the REST normalizer never sees.
+
+  | `orderBy` you send                                     | Before                      | After                                                       |
+  | :----------------------------------------------------- | :-------------------------- | :---------------------------------------------------------- |
+  | `[{ field: 'x', order: 'desc' }]`                      | descending                  | unchanged — descending                                      |
+  | `[{ field: 'x', direction: 'desc' }]`                  | **200, ascending**          | `400 INVALID_SORT`, message names `order`                   |
+  | `[{ field: 'x', order: 'desc', direction: 'asc' }]`    | 200, descending             | `400 INVALID_SORT`                                          |
+  | `'-x'` / `['-x']` / `{ x: 'desc' }`                    | descending                  | unchanged                                                   |
+  | `{ direction: 'desc' }` (the `{field: direction}` map) | sorts by column `direction` | unchanged — a column may legitimately be called `direction` |
+
+  Scope is deliberately narrow: **`QuerySchema`'s top level is untouched** and
+  still accepts undeclared keys (`QuerySchema.safeParse({ object: 'sales',
+nonsenseKey: 1 }).success === true`). That is tracked in the #4001 campaign map
+  for its own batch, not smuggled in here.
+
+  Related: #4674, #4720, #4363, #4371, #4001, ADR-0049.
+
+### Minor Changes
+
+- 77022a9: feat(spec,runtime,metadata-protocol)!: one schema for both discovery producers — `capabilities` canonical, `features`/`endpoints` retired, `scoping` declared (#4828)
+
+  `/discovery` is a machine-readable surface, but nothing compared what the two
+  producers emit against what `packages/spec` declares. The only schema the
+  protocol layer referenced was `GetDiscoveryResponseSchema` —
+  `DiscoverySchema.partial().required({version}).extend({apiName})` — so
+  `.partial()` hid every missing REQUIRED key while zod's default unknown-key
+  strip hid every UNDECLARED emitted one. The two producers then drifted in
+  opposite directions through the same blind spot.
+
+  `DiscoverySchema` is now authoritative for producers, and each producer package
+  carries a `discovery-schema-conformance.test.ts` that parses its LIVE shape
+  against it and checks its emitted key set against the protocol schema's shape.
+
+  **Breaking for anyone reading the dispatcher's `/.well-known/objectstack` body:**
+
+  - `features` → **`capabilities`**, the name `DiscoverySchema` has always
+    declared, in the declared `{ enabled }` shape. The same flags survive. This
+    fixes a real defect: the SDK's `client.capabilities` getter reads
+    `discoveryInfo.capabilities`, so against a dispatcher-served host it returned
+    `undefined` for every flag while the answers sat one key away under `features`.
+  - `endpoints` — **removed**. It duplicated `routes` verbatim as a
+    "backward compatibility" alias; a consumer census across `objectstack`,
+    `objectui` and `cloud` found no reader. Use `routes`.
+  - `environment` is now **mapped** into its declared enum instead of passing
+    `NODE_ENV` through raw (`test` → `development`, `staging` → `sandbox`,
+    unrecognized → `development`, never `production` on a guess). `NODE_ENV=test`
+    and `staging` previously advertised values outside the declared enum.
+
+  **Additive elsewhere:**
+
+  - `DiscoverySchema` declares `scoping` (optional) — the environment-scoping
+    posture the REST endpoint has always emitted and `packages/client` has always
+    consumed, now part of the contract instead of an undeclared extra.
+  - The REST `/discovery` body gains the required `name` / `environment` /
+    `locale`, so it can satisfy `DiscoverySchema` at all. `locale` is derived from
+    the registered i18n service, the same way the dispatcher derives it.
+  - `name` is canonical on both producers. `apiName` remains as a deprecated alias
+    carrying the identical value and is **scheduled for removal in protocol 18**.
+  - New exports: `DiscoveryEnvironmentSchema`, `DiscoveryEnvironment`,
+    `resolveDiscoveryEnvironment`.
+
+- aac90a5: feat(spec,runtime,metadata-protocol,client)!: one closed capability vocabulary — every discovery producer emits every key (#5672)
+
+  `#4828` renamed the runtime dispatcher's top-level `features` map to the
+  canonical `capabilities`, which collapsed the _spelling_ split between the two
+  discovery producers. It did not touch the deeper one: the two went on filling
+  **disjoint key sets**.
+
+  | producer                                                                             | keys it filled                                                                        |
+  | :----------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------ |
+  | `getDiscovery()` — `@objectstack/metadata-protocol`, upstream of REST `/discovery`   | `comments` `automation` `cron` `search` `export` `chunkedUpload` `transactionalBatch` |
+  | `getDiscoveryInfo()` — `@objectstack/runtime` dispatcher, `/.well-known/objectstack` | `search` `websockets` `files` `analytics` `ai` `notifications` `i18n`                 |
+
+  Only `search` overlapped. `DiscoverySchema.capabilities` was an open
+  `z.record`, so both shapes parsed clean and no gate could see the split — while
+  `packages/client`'s `capabilities` getter **asserted** the result was a
+  `WellKnownCapabilities`. Against a dispatcher-served host
+  `client.capabilities.transactionalBatch` was therefore statically `boolean` and
+  actually `undefined`, as were `comments`, `cron`, `export` and `chunkedUpload`.
+
+  Per the maintainer's 2026-08-06 ruling, the vocabulary is now closed and
+  mandatory.
+
+  **What a consumer sees.** Before: which capability flags exist depended on
+  which kind of host answered, and a flag you were typed to receive could simply
+  be missing. After: every discovery response carries **every** flag, always a
+  boolean. A capability the host does not deliver is `enabled: false` — never an
+  absent key — so a client can read a flag without knowing whether it reached a
+  dispatcher, the REST endpoint, or anything else. `client.capabilities` no longer
+  asserts its own return type: it enumerates the spec's key list, so the type is
+  true by construction, and it reads a key an older server omits as `false`
+  (fail-closed, matching the wire rule).
+
+  **`@objectstack/spec`.** `WellKnownCapabilitiesSchema` becomes the one
+  vocabulary and gains the six flags that were previously the dispatcher's alone
+  (`websockets`, `files`, `analytics`, `ai`, `notifications`, `i18n`) — all six
+  were already real answers on the wire, so this declares them rather than
+  inventing them. `DiscoverySchema.capabilities` changes from an optional open
+  record to a **required closed object** derived from that vocabulary, one entry
+  per key. New exports: `WELL_KNOWN_CAPABILITY_KEYS` (the key list, derived from
+  the schema so nothing can hand-list a fourth dialect) and
+  `CapabilityDescriptorSchema` / `CapabilityDescriptor` (the `enabled` +
+  optional `features` / `description` entry shape, previously inline).
+
+  Required, not optional, is the `scoping` precedent read the other way round:
+  `scoping` is optional because only one producer can honestly answer it, whereas
+  every producer can answer `capabilities` — and an optional block would leave a
+  consumer back at `undefined` for every flag.
+
+  **Producers.** Each answers all thirteen keys from its own facts, with the basis
+  recorded per key in the code. The dispatcher now measures `comments` off the
+  `sys_comment` object in the registry it already resolves for its `/data` domain,
+  and `automation` / `cron` / `export` / `chunkedUpload` off the same service
+  predicates that gate its route advertisements. Its one honest `false` is
+  `transactionalBatch`: the atomic cross-object `/batch` route is mounted by
+  `@objectstack/rest`, and this dispatcher has no batch branch at all, so claiming
+  the runtime's `transaction()` here would advertise an endpoint the host does not
+  serve. `getDiscovery()` answers the six new flags off the service registry it
+  already reads, gated on serveability so a self-declared stub does not advertise
+  a capability it cannot back.
+
+  **Gates.** The three `discovery-schema-conformance.test.ts` suites built by
+  `#5682` and extended to `routes` by `#5743` gain a fullness criterion — every
+  vocabulary key present, every `enabled` a real boolean, no key outside the
+  vocabulary — with the allowance derived from the schema rather than written out.
+
+  **Upgrading.** A producer or fixture that builds a `DiscoverySchema`-shaped
+  document must now include a complete `capabilities` block; build it from
+  `WELL_KNOWN_CAPABILITY_KEYS` rather than by hand. Consumers need no change:
+  they receive strictly more keys than before, and any flag they already read
+  keeps its meaning. The lenient wire wrapper `GetDiscoveryResponseSchema` still
+  allows the block to be absent, so a response from an older server still parses.
+
+### Patch Changes
+
+- 29c6c9d: feat(spec,core,runtime)!: declarative `apis:` refuses loudly instead of parsing into silence; the `ApiRegistry` family retires (#4936, #4939)
+
+  The declarative API-endpoint surface was **zero-execution end to end**, and said nothing
+  about it. Metadata loading worked perfectly — a stack declared `apis:`, `defineStack`
+  accepted it, and `GET /api/v1/meta/api` returned every endpoint with every key intact.
+  The execution side never fired once. On a real boot (showcase, 47 plugins) both declared
+  paths answered a bare `404 {"error":"Not found"}` — not even the dispatcher's semantic
+  404, because **no route was ever mounted** for a declared path, so the request died at
+  Hono's `notFound`. Behind that, the dispatcher's `handleApiEndpoint` branch resolved the
+  metadata service and called `matchEndpoint` on it — a method **no implementation in the
+  repo has ever provided**. The branch returned "not handled" on every request ever served.
+
+  So every key on `ApiEndpointSchema` was declared ≠ enforced: `path`/`method` (never
+  mounted), `type`/`target`/`objectParams` (never executed), `cacheTtl`,
+  `inputMapping`/`outputMapping`, `rateLimit`, `summary`/`description` — and
+  **`authRequired`**, a security semantic that parsed green and gated nothing at all. That
+  is false compliance, the failure ADR-0049 exists to stop, not debt.
+
+  ## BREAKING — a non-empty `apis:` is now rejected
+
+  Metadata that parsed cleanly before is now **refused at publish/validate**, with the
+  prescription in the rejection itself:
+
+  ```
+  apis: `apis:` (declarative ApiEndpoint) is DECLARED BUT NOT EXECUTABLE in this runtime,
+  so a non-empty array is rejected instead of silently accepted (#4936). …
+  ```
+
+  **FROM → TO.** `apis: [ …endpoints… ]` → `apis: []` (or delete the key; both are still
+  accepted, and an empty array is not a special case). To actually serve the route today,
+  mount it **in code** — a plugin manifest `contributes.routes` entry, or an `http.server`
+  route. That is now the only honest path, and the one `examples/app-showcase` uses
+  (`src/system/server/recalc-endpoint.ts`).
+
+  The refusal lives on `ObjectStackDefinitionSchema` itself, which is the single choke
+  point every path runs through — `defineStack`, the metadata plugin's artifact ingestion,
+  `os validate`, the lint scorer and `EnvironmentArtifactSchema`. There is no path that
+  forgot to check.
+
+  **The `ApiEndpoint` vocabulary is deliberately KEPT.** Retiring it was considered and
+  rejected: endpoint shapes are an industry-stable form, so a retirement would only mean
+  re-introducing the identical schema later. Your endpoint definitions stay valid TypeScript
+  and stay in the spec; only _authoring them into a stack_ is refused, and only until the
+  executor lands. Keep them commented next to your stack — that is what the showcase does.
+  The executor (route mounting + endpoint matching + per-key wiring for
+  `authRequired`/`cacheTtl`/`inputMapping`/`outputMapping`/`rateLimit`) is tracked by
+  **#5040**, which replaces this rejection with real execution.
+
+  ## BREAKING — the `ApiRegistry` / `ApiEndpointRegistration` family is removed (#4939)
+
+  The repo carried a **second**, unrelated declaration shape for "an API endpoint":
+  `ApiEndpointRegistrationSchema` and the ~500-line `ApiRegistry` service that
+  `createApiRegistryPlugin()` registered under `api-registry`. Nothing composed it — every
+  assembly site lived in `packages/core/examples/`, with no registration in
+  `packages/runtime`, `packages/cli` or any `examples/app-*`, and a real boot carried no
+  such service. The whole family was therefore inert, including
+  `ApiEndpointRegistration.requiredPermissions`, whose docs promised **in the present tense**
+  that "the gateway layer automatically validates these permissions" while no gateway read
+  it. Two declaration shapes, both dead; this retirement converges them on one.
+
+  Removed from `@objectstack/spec/api`: `ApiEndpointRegistration(Schema)`,
+  `ApiRegistry(Schema)`, `ApiRegistryEntry(Schema)`, `ApiMetadataSchema`,
+  `ApiParameterSchema`, `ApiResponseSchema`, `ApiDiscoveryQuerySchema`,
+  `ApiDiscoveryResponseSchema`, `ApiProtocolType`, `HttpStatusCode`,
+  `ObjectQLReferenceSchema`, `SchemaDefinition` (12 JSON-Schema defs, 67 authorable keys).
+  Removed from `@objectstack/core`: `ApiRegistry`, `createApiRegistryPlugin`.
+  Removed from `@objectstack/plugin-hono-server`: the `useApiRegistry` option — it was
+  defaulted to `true` and read by nothing, configuring a service that was never composed.
+
+  **FROM → TO.** There is no replacement shape to migrate to, because nothing executed the
+  old one: delete the registration objects. If you were assembling an `ApiRegistryEntry`,
+  you were building a value only your own code read — keep it as your own type. Declarative
+  endpoints have one vocabulary now, `ApiEndpointSchema`.
+
+  `ConflictResolutionStrategy` **survives** the removal and moved to
+  `@objectstack/spec/api`'s `router.zod` — same name, same four values
+  (`error`/`priority`/`first-wins`/`last-wins`), same import path. It is pinned there by two
+  independent ratchets and is not part of the retired surface.
+
+  ## Also in this change
+
+  - **BREAKING (`@objectstack/runtime`):** `HttpDispatcher.handleApiEndpoint()` is deleted,
+    along with its now-orphaned private `callData` delegate, and `/__api-endpoint` leaves
+    `LEGACY_CHAIN_PREFIXES` and the route ledger. The method was public, so this is an API
+    removal — but it returned `{ handled: false }` for every call it ever received, so no
+    caller can observe a behaviour change beyond the missing symbol. Delete the call.
+    Absence is now loud (ADR-0076): the surface is refused at authoring rather than 404ing
+    at runtime with dead code behind it.
+  - `examples/app-showcase` no longer declares endpoints, and its coverage manifest no
+    longer claims the capability is `demonstrated` — that entry read "executed by the runtime
+    dispatcher (handleApiEndpoint)", which was exactly the advertise-what-you-don't-deliver
+    claim Prime Directive #10 forbids.
+  - The endpoint-level `rateLimit` tracking pointers left by #4910/#5006 now name **#5040**,
+    the live executor card, instead of #4936, which closes with this change.
+
+- c497d26: fix(objectql): `autonumber` 是运行时拥有的字段,写路径不再接受调用者提交的单号 (#5503)
+
+  `autonumber` 的值一直被文档声明为运行时所有 —— `applyAutonumbers` 的注释写着
+  "the runtime owns the value, not the client",两个记录校验器也正是因此在 insert
+  与 update 上都豁免了 `required` 检查。缺的是另一半:**没有任何一层写路径阻止客户端
+  自己填这个值**。于是一个普通的 REST 调用者可以:
+
+  - `POST /data/:object` 携带显式单号 → 原样落库,序列被绕过;
+  - `PATCH /data/:object/:id` 携带该字段 → 200 且改写落库,业务单号被篡改。
+
+  这与已修复的 #4447(`created_at` 可被普通 PATCH 伪造)是同一缺陷族。区别在于:
+  声明了 `readonly: true` 的字段早已被 #2948 / #3043 的剥离机制保护,而 `autonumber`
+  字段身上根本没有这个标记,剥离循环从它旁边直接走过去了。
+
+  **修法:在引擎/校验层把 `type: 'autonumber'` 视为隐含 readonly,insert 与 update
+  同权。** 非 system 上下文提交的单号,在派发给任何驱动之前就被剥离:
+
+  - **UPDATE** —— `stripReadonlyFields`(`packages/objectql`)的判定从"作者声明的
+    `readonly: true`"扩展为"作者声明的 **或** 运行时拥有的字段类型"
+    (`isRuntimeOwnedField`,当前恰好只有 `autonumber`)。单行更新与 `multi` 批量更新
+    共用这一个剥离点,因此两条路径同时被覆盖。
+  - **INSERT** —— 引擎新增一个更窄的 `stripRuntimeOwnedFields`,只剥离运行时拥有的
+    字段。它**不**接管作者声明的 `readonly` 在 insert 上的语义:那条防线按 #3413 的
+    设计留在 DataProtocol 入口(#3043),因为 create 确实可能合法地写入只读列,而直接
+    调用 `engine.insert` 的可信内部写入者(身份预置、元数据仓库、事件游标)必须不受影响。
+    单号没有这种两可性 —— 谁都不该在 create 时自带单号。
+
+  剥离发生在引擎里、派发之前,这正是修复**与驱动无关**的原因:声明
+  `supports.autonumber === true` 的 SQL 驱动(持久序列)拿到的行里根本没有这个键,
+  所以它的序列必然胜出 —— 没有任何驱动需要改动一行代码。测试直接断言递交给
+  `driver.create` 的负载,而不是打补丁到驱动上。
+
+  **豁免语义保持不变**,与 update 侧原有的白名单完全一致:
+
+  - `isSystem` 写入(seed 回放、迁移、内部预置)整体跳过剥离;
+  - `preserveAudit`(#3493)的"历史数据导入"仍可写入原始单号 —— 把遗留系统的历史
+    单号迁移进来正是这个白名单存在的业务场景,而 `autonumber` 属于作者声明的业务字段
+    (`system !== true`),恰好落在 `isPreservableUnderAudit` 允许的范围内;
+  - `beforeInsert` / `beforeUpdate` 钩子计算出的值不受影响 —— 只有**调用者提交**的键
+    才是剥离候选。
+
+  **这是一次静默剥离,所以它被上报而不是被吞掉。** 引擎 insert 路径上的
+  `onFieldsDropped`(#3407)此前只是为了与 `update()` 对称而存在、从不触发,并留了一
+  句"若 insert 将来出现静默剥离,必须在剥离点接上监听器"——现在正是那个剥离点。
+  事件沿用既有的 `readonly` 原因码(对调用者而言,隐含只读与声明只读被丢弃的理由完全
+  相同,不值得为一个没有消费者会区分的差别在 `packages/spec` 里分叉词表)。
+  `createManyData` 与 `insertManyData` 也补上了监听器转发:后者保持**逐行精度**——
+  引擎事件是整批的并集,但剥离只会移除**行自身提交过**的键,因此可以准确归属回具体行。
+  导入器优先走的正是 `insertManyData` 这条部分成功路径。
+
+  **与 `strictReadonlyWrites`(#5126 / #5610)叠加。** 该开关是"剥离即拒绝"的进程内出路,
+  本次改动使它自然覆盖单号,两条路径同权:
+
+  - **UPDATE 无需新代码** —— autonumber 限肢走的正是 `stripReadonlyFields` →
+    `reportDroppedFields` → `assertNoStrictDrops` 这条 #5126 已经铺好的接缝,因此 strict
+    开启时,调用者提交的单号与声明 `readonly` 的字段一样被拒绝,整笔写入不落库;
+  - **INSERT 需要接上** —— #5126 当时把该开关在 insert 上留作惰性,并写下条件:"insert
+    一旦有了剥离,两个成员就在那个剥离点一起接上"。本次正是那个剥离点,于是
+    `onFieldsDropped` 与 `strictReadonlyWrites` 一并兑现:默认剥离+上报,strict 开启则在
+    任何驱动调用之前抛 `ERR_READONLY_FIELD_REJECTED`,且**监听器不触发**(被拒绝的写入
+    并未完成,这是 #5126 自己的设计要点)。
+
+  接缝处**没有新增任何策略**:#5126 明确写着 strict "不引入第二套策略,它只是把既有策略
+  报出来",且"剥离拿不走的字段也不会被拒绝"。照此逐字适用,`isSystem` 与 `preserveAudit`
+  两个豁免在 strict 下依旧被接受(它们根本不会走到剥离分支)。
+
+  `ReadonlyFieldRejectedError` 新增可选的 `operation`(默认 `'update'`,#5126 的 UPDATE
+  文案逐字节不变):动词与补救办法确实因操作而异 —— INSERT 的拒绝必然关于运行时拥有的值,
+  其合法写入者是 `isSystem` 与历史导入 `preserveAudit`,而 `readonlyWhen` 在 create 上
+  根本锁不住任何东西。
+
+  **升级影响。** 普通(非历史)导入若把遗留单号列映射到 `autonumber` 字段,该值现在会
+  被丢弃并改由序列发号,同时在响应的 `droppedFields` 里上报、在服务端日志里留下一条
+  带补救办法的 `warn`。要保留原始单号,请把导入标记为历史导入
+  (`treat_as_historical` → `preserveAudit`),这与 #3493 为只读业务字段确立的划分一致。
+
+  `packages/spec` 未改动:`autonumber` builder 是否应当直接注入 `readonly: true` 是
+  spec 层的独立议题,与这条引擎侧防线不冲突。
+
+- e96ad55: fix(metadata-protocol): `batchData`'s upsert fork decides update-or-insert by EXISTENCE, not caller visibility (#5099)
+
+  The fork asked `findOne` under the CALLER's context — the read RLS/sharing
+  narrows (#3455). An existing row outside the caller's read scope therefore
+  answered `null` and took the INSERT arm: on a store with a unique id constraint
+  the insert duplicate-keyed (an authorization/update scenario reported as a key
+  collision — the same misdirection class as #5088), and on a store without one
+  it wrote a **second row** for an id that already exists.
+
+  The fork now uses the same existence probe (`probeRecord`, system context) as
+  the single-record path and the update/delete bulk faces (#4620: one reading per
+  file). Whether the caller may WRITE the row it proves stays exactly where it
+  was — #1994's pre-image check inside `engine.update` — so the row's outcome is
+  the write policy's own answer instead of a spurious `duplicate key` error.
+
+  **Observable change under row-level visibility**: upserting an id that exists
+  outside your read scope no longer attempts an insert. The row now answers
+  whatever the by-id update path answers for that record (for a masked pre-image
+  check, the same 404 a direct update returns). The existence oracle is not
+  widened: the previous duplicate-key failure already revealed that the id
+  exists.
+
+  The non-atomic fallback (update threw → blind insert) is removed with it, on
+  both arms. With existence decided before the fork, the fallback could only
+  bury a real update failure under the duplicate-key error of inserting a row
+  just proven to exist — the same masking ADR-0119 D4 already forbade inside the
+  atomic arm. A row whose update fails now reports that failure.
+
+  Cost note: each by-id upsert row now performs one existence read before the
+  write — the same probe cost #4435 accepted for the single-record path and
+  #5088 accepted for the update/delete bulk faces.
+
+- bbdbf28: fix(metadata-protocol,objectql): a boot that could not read `sys_metadata` says so at `error`, instead of reporting "no persisted metadata" at debug (#5897)
+
+  `loadMetaFromDb` — the boot step that hydrates `sys_metadata` overlay rows into
+  the SchemaRegistry — returned `{ loaded, errors, invalid }`, and no field in
+  that shape could express **"this hydration never read the store"**. An
+  unreachable database and a genuinely empty one both answered `loaded: 0`.
+
+  Its only production consumer, `ObjectQLPlugin.restoreMetadataFromDb`, therefore
+  had nothing to branch on: its single branch chose between two log lines, and
+  the "nothing came back" side was
+  `logger.debug('No persisted metadata found in database')`. So a kernel that
+  could not read a word of its persisted metadata stated at **debug** level that
+  there was none, and went on to report ready.
+
+  What that costs is not hypothetical — it is written into the plugin's own
+  Phase 2 comment. With the registry empty, `registry.getObject` answers "not
+  declared" where the truth is "we could not look": unknown-column query guards,
+  hooks and relationships silently degrade, and overlay objects get neither a
+  synced table nor a metadata bridge. This is ADR-0110 D3 (an outage is not a
+  miss) on the boot side, after the same rule landed for `DatabaseLoader`
+  (#5108), `listForIndex` (#5089) and the overlay reads (#5532 / #5707).
+
+  **What changed**
+
+  - `loadMetaFromDb` returns `storeUnavailable: boolean`, set on exactly the
+    branch that already prints `[Protocol] DB hydration skipped` — a read that
+    failed for a reason `isMissingTableError` does _not_ call benign. A store
+    that has merely not been provisioned yet (first boot, before migrations)
+    keeps `storeUnavailable: false`, because `loaded: 0` genuinely is the truth
+    there (#5841).
+  - `restoreMetadataFromDb` reads it and logs at **`error`**, naming the
+    consequence (nothing was restored, the kernel keeps reporting healthy, and
+    which capabilities silently degrade) and the fix (check the datasource behind
+    `sys_metadata` — connection, credentials, table existence — then restart).
+    Per AGENTS.md "Degradation log levels": persisted state and runtime state
+    disagreeing while the system still looks healthy is the `error` class. An
+    empty-but-readable store keeps its quiet debug line, so first boots do not
+    start emitting durability errors.
+
+  **Not changed**: control flow. Boot still degrades and continues — refusing to
+  boot on an unreadable overlay store would turn a transient outage into an
+  outright one. What changes is that the degradation is now distinguishable from
+  health, and reported as such.
+
+  **Impact on duck-typed `ProtocolWithDbRestore` implementers**: none required.
+  `ObjectQLPlugin` matches the `protocol` service structurally, and the new field
+  is declared **optional** on its side of the contract, exactly as `invalid`
+  already is. A shim that predates the field keeps type-checking and is read as
+  "not an outage" — the only verdict it was able to express before — so its
+  behaviour is byte-for-byte what it was. The trade-off is deliberate and worth
+  naming: an optional field cannot _force_ a third-party shim to start reporting
+  outages, so such a shim stays as silent as it is today. Requiring the field
+  would have made that impossible to ignore at the cost of breaking every
+  external implementer for a bit only one in-repo producer sets; the in-repo
+  producer (`ObjectStackProtocolImplementation`) declares and returns it
+  **required**, so the path that actually runs in every ObjectStack kernel is
+  fully covered.
+
+- 75bb3af: fix(metadata-protocol): the by-id BULK write faces refuse a row that names no record (#5088)
+
+  `updateMany`, and `batch`'s `update` and `delete` branches, now answer
+  `RECORD_NOT_FOUND` (404) for a row whose id resolves to nothing — the same code
+  and the same message (`Record <id> not found in <object>`) the single-record
+  `PATCH` / `DELETE` have answered since #4435.
+
+  Before this, #4435's "a write that touched zero rows must not report success"
+  was live on only 2 of the 5 write faces in `protocol.ts` (`updateData`'s
+  existence probe and `deleteMany`'s `deleted === false`). The three bulk faces
+  went straight to the engine, with two visible consequences:
+
+  - **`updateMany` / `batch.update`** — a stale id entered the write pipeline.
+    With no stored row to overlay, #4770's record materialisation (stored ⊕
+    payload) produced a payload-only record, a hook `condition` reading any
+    untouched field found it absent, and #4775's unevaluable-condition abort
+    fired. The row failed `INTERNAL_ERROR` with a diagnostic accusing a _correct_
+    hook of naming an undeclared field, so an operator with one stale id in a
+    batch was told their hook was broken and pointed at the object's field list.
+    Under `atomic: true` that row also poisoned the batch, taking every later row
+    to `NOT_ATTEMPTED`. Hooks, automation and audit rows no longer fire at all for
+    a record that does not exist.
+  - **`batch.delete`** — discarded the driver's return and reported
+    `success: true` unconditionally, so a batch of typo'd ids reported every one
+    of them deleted. It now reads the driver contract's positive not-found value
+    (`=== false`), exactly as `deleteMany` does.
+
+  Existence is asked with the same `probeRecord` the single-record path uses: it
+  answers EXISTENCE, not visibility, so the by-id write policy stays #1994's
+  decision inside `engine.update` and the `rls-by-id-write` proof can still go
+  red. `upsert` is deliberately unchanged (a missing id still inserts), as are
+  the predicate bulk writes (`multi: true`, no per-row id) and the `atomic`
+  response shape — the causal row keeps its position, later rows stay
+  `NOT_ATTEMPTED`, and rows with real ids behave exactly as before.
+
+  Note for high-volume callers: each by-id row in these three faces now costs one
+  extra existence read before its write.
+
+- 43ca399: fix(runtime): `callData`'s ObjectQL fallback answers a missing record id with 404 `RECORD_NOT_FOUND` (#5138)
+
+  `callData` (the data bridge behind `/data`, the MCP bridge and the declarative
+  endpoint executor) is protocol-first with an ObjectQL fallback. The fallback
+  gave **three different answers to one fact** — that `id` names no row:
+
+  | verb     | before                                                      | on the wire             |
+  | -------- | ----------------------------------------------------------- | ----------------------- |
+  | `get`    | `return … : null`                                           | `200 { data: null }`    |
+  | `update` | `throw new Error('[ObjectStack] Not Found')` — no `.status` | **500**                 |
+  | `delete` | no existence check at all                                   | `200 { deleted: true }` |
+
+  The protocol path has answered `404 RECORD_NOT_FOUND` on all three verbs since
+  #4435 (re-asserted for the batch path by #5088), so the answer to the same
+  request depended on something no caller can see: whether the deployment
+  registered the `protocol` slot (`MetadataPlugin` / `@objectstack/metadata-protocol`).
+  All three fallback branches now throw the SAME envelope the protocol throws.
+
+  Two of these were actively harmful. `update` reported a caller mistake as an
+  internal fault — every dispatcher exit reads `.status` → `.statusCode` → 500, so
+  a 4xx fact entered error reporting and alerting as a 5xx. `delete` reported
+  success for a row that never existed, which is the hardest class to notice: an
+  integrator reading `200` records the cleanup as done.
+
+  The envelope is not re-spelled. `recordNotFoundError` is now exported from
+  `@objectstack/metadata-protocol` and imported by the fallback, so there is one
+  construction point and the two paths behind one `callData` cannot drift apart
+  again.
+
+  **Upgrade note.** If you run an assembly WITHOUT the metadata-protocol plugin
+  (lean hosts, and the MCP multi-env path that threads a raw driver), these three
+  calls change their answer for a missing id — from `200`/`200`/`500` to `404
+{ code: 'RECORD_NOT_FOUND', message: 'Record <id> not found in <object>' }`.
+  Deployments that DO register the protocol slot are unaffected: they already
+  answered `404` and this release does not touch that path. A client that
+  branched on `data === null` from `GET /data/:object/:id` should branch on the
+  `404` instead; a client that treated `DELETE` as idempotent should treat `404`
+  as "already gone". Declarative endpoints (`object_operation`) inherit the same
+  answer, since they reuse `/data`'s delegation.
+
+  `delete`'s existence check is a `find` probe, not a read of what `ql.delete`
+  returned: `IDataDriver.delete` declares `Promise< boolean >` and the protocol
+  can read it, but `IDataEngine.delete` declares `Promise< any >` and the engine
+  returns its driver's result through the hook chain — testing that for `false`
+  would be reading a signal the contract does not promise, and it fails in the
+  direction this fixes.
+
+- 1f82d1e: fix(metadata-protocol): `allowRuntimeCreate: false` is enforced on every kernel — `PUT /meta` no longer creates `job` / `agent` items the registry declares code-only (#5086)
+
+  #4509 set `allowRuntimeCreate: false` on `job` and promised the refusal without
+  qualification — _no "create job" in Studio or via `PUT /meta`_. ADR-0063 §2 says
+  the same for `agent`. The gate that keeps that promise existed, and worked, but
+  it sat behind `environmentId !== undefined`:
+
+  ```ts
+  if (this.environmentId !== undefined) {
+    // …not_overridable / not_creatable…
+  }
+  ```
+
+  `environmentId` is a **row-scoping key**, not an authorization signal. Every
+  kernel assembled without one ran with the entire ADR-0005 authorization gate
+  disengaged — and that is not an exotic topology. The CLI's lightweight
+  assembler builds exactly that for a host config (`isHostConfig` → the
+  `createStandaloneStack` branch is skipped → `new ObjectQLPlugin()` with no
+  `environmentId`), which is the flagship showcase and every self-hosted app
+  server shaped like it. On those, the issue's repro answered:
+
+  ```
+  PUT /api/v1/meta/job/rc3_runtime_job
+      {"name":"rc3_runtime_job","label":"J",
+       "schedule":{"type":"cron","expression":"0 0 * * *"},"handler":"nope"}
+  → 200 {"success":true,"message":"Saved customization overlay (env-wide) — type=job, …"}
+  ```
+
+  `handler: "nope"` names no function in any compiled bundle. The row persists,
+  lists, and can never be scheduled — the record #4509 exists to prevent, saved
+  and reported as success. It is the ADR-0049 failure mode one level up: the
+  _enforcement flag itself_ was the silently-inert declaration, and Studio (which
+  reads the flag to hide "create") honoured a rule the API underneath did not.
+
+  **What changed.** A type whose registry entry sets BOTH `allowRuntimeCreate:
+false` AND `allowOrgOverride: false` declares that it has no runtime write
+  channel at all. `saveMetaItem` now refuses it on every kernel, before
+  persistence, in draft mode as well as publish:
+
+  | write                                       | before        | now                   |
+  | ------------------------------------------- | ------------- | --------------------- |
+  | `PUT /meta/job/*` on a single-kernel host   | `200 success` | `403 NOT_CREATABLE`   |
+  | `PUT /meta/agent/*` on a single-kernel host | `200 success` | `403 NOT_CREATABLE`   |
+  | same, over a name a code package ships      | `200 success` | `403 NOT_OVERRIDABLE` |
+  | project-scoped (cloud) kernels              | `403`         | `403` (unchanged)     |
+
+  The refusal names the type, the flags that produced the verdict, the source
+  file pattern to declare it in (read from the type's own registry entry, so a
+  newly-flagged type carries an accurate hint the day it is flagged) and the
+  `OS_METADATA_WRITABLE` escape hatch.
+
+  **Scope, deliberately.** The rest of the ADR-0005 two-tier gate keeps its
+  single-kernel carve-out: that ADR's "single-kernel deployments keep their
+  existing behaviour" sentence is about the _overlay whitelist_, predates
+  `allowRuntimeCreate` entirely, and a type that stays runtime-creatable
+  (`object`, `hook`, `field`, `seed`, `mapping`, …) is untouched here. So is
+  `deleteMetaItem` — removing a code-only row that predates this refusal is
+  repair and must stay possible. `OS_METADATA_WRITABLE` remains the one door:
+  unlocking a type there unlocks it here too.
+
+  **Upgrading.** If a deployment relies on runtime-created `job` or `agent` rows,
+  move them into source (`**/*.job.ts`, `**/*.agent.ts`) and redeploy — a `job`
+  authored at runtime never had a reachable `handler` in the first place. To keep
+  writing them while migrating, set `OS_METADATA_WRITABLE=job,agent`.
+
+- 65159ae: fix(metadata-protocol): 分层读的 overlay 读失败不再被画成「这一项没有定制」(#5707)
+
+  `getMetaItemLayered` 是 Studio「code / overlay / effective」对比视图背后的那次读
+  (`GET /api/v1/meta/:type/:name?layers=true`)。它的 `sys_metadata` overlay 读裹着一个
+  裸 `catch`,注释写着 "DB unavailable — overlay stays null" 然后照「没有 overlay 行」
+  返回。
+
+  那不是一个中性的兜底值。这个信封在**同一次响应里同时给出三个正面断言**,而且是 200:
+
+  - `overlay: null` —— 「这一项从来没有被定制过」;
+  - `overlayScope: null` —— 「org 和 env 两个作用域都没有行」;
+  - `effective === code` —— 「现在生效的就是打包件原样」。
+
+  对比视图存在的意义正是回答作者「我改过什么」。故障期它回答「什么都没改过」——
+  和 #5532 同一个错误(可用性故障被讲成作者的声明事实),只是落在 diff 视图而不是 404 上。
+  本次沿用 #5532 / PR #5705 的判定,补上该 PR 按 scope 刻意没有覆盖到的这一处读。
+
+  **改了什么**:这一处 `catch` 改为调用同文件的 `rethrowUnlessMetadataStoreUnprovisioned`
+  —— `isMissingTableError`(表尚未建 → 确实没有 overlay 行)良性放行,其余上抛
+  `status: 503` / `code: SERVICE_UNAVAILABLE`,驱动原始错误挂在 `cause` 上。没有新增
+  判定逻辑,也没有新的返回形状:分层信封仍是 code / overlay / effective 三**层**,而不是
+  每层三**态** —— 「读不到」不是一层,所以照失败上报,不再冒充某一层的取值。
+
+  **wire 可见变化**
+
+  | 场景                           | 之前                                                                | 之后                                                     |
+  | ------------------------------ | ------------------------------------------------------------------- | -------------------------------------------------------- |
+  | `sys_metadata` 不可达          | `200` + `overlay: null` / `overlayScope: null` / `effective = code` | `503` + `SERVICE_UNAVAILABLE`(`cause` 带驱动报文),可重试 |
+  | org 作用域读失败、env 行本可读 | `200`,连那行 env overlay 也一并报告为「没有」                       | `503`,同上                                               |
+  | `sys_metadata` 尚未建表        | `200` + 只有 code 层                                                | 不变                                                     |
+  | 存储正常                       | 不变                                                                | 不变                                                     |
+
+  REST 侧无需改动:`?layers=true` 与普通读共用同一个 `handleRouteError`,#5437 / #5464
+  的消毒与日志口原样接住。已测量的消费方处置也都已就位:objectui 的
+  `MetadataClient.layered()` 对非 2xx 一律 `throw`(只有 404 映射为空信封),
+  ResourceEditPage 的加载 `try/catch` 把它渲染成错误态而不是空白页;
+  `plugin-security` 的三个消费点里,两处本就有 `catch` 兜底,唯一没有的
+  `projectPermissionMutation` 在 503 化后反而更安全 —— 此前的静默 `null` 会让权限集
+  投影悄悄退回打包基线(`customized: false`),没有 declared body 时甚至会把记录
+  retire,而协议的 `runMutationProjector` 契约是 never throws,会把 503 收敛成
+  `projectionApplied: { success: false }`。
+
+- 877545c: `MetadataProtocol.listCommits` 不再把 commit store 读不到答成「这个 package 没有提交历史」
+
+  `listCommits` 读 `sys_metadata_commit` 的 `catch` 此前对任何失败都返回 `[]`,零日志、不按错误类型区分 —— 它的 JSDoc 甚至把这写成了设计(“Returns [] if the commit store is unavailable”)。于是 ADR-0067 的提交时间线上,「确实没有历史」与「有历史但库读不到」返回值完全一致,而这条时间线正是 `revertCommit` 的选择面:故障期间 UI 显示「无可回滚项」,`rollbackToPackageCommit` 更会在一次都没回滚的情况下返回 `success: true`。
+
+  现在按错误类型区分,与本文件既有的 `sys_metadata` 覆盖层读法(#5532 / #5707 / #5840)同一处方:表未 provision(首启)仍返回 `[]`;其余失败一律包成 503 `SERVICE_UNAVAILABLE` 上抛,驱动原始错误挂在 `cause` 上。调用方由此能把 outage 与 miss 分开。
+
+  行为变化:`GET /packages/:id/commits` 在 commit store 故障时返回 503 而不再是 `{ commits: [] }`。
+
+- 444a07c: fix(metadata-protocol): boot hydration classifies "store not provisioned yet" by error type, not by a copied message regex (#5841)
+
+  `loadMetaFromDb` — the boot step that hydrates `sys_metadata` overlay rows into
+  the SchemaRegistry — decided whether a failed read was the benign first-boot
+  case by running its own `/no such table/i` over `e.message`. That was a second,
+  hand-copied vocabulary of "which driver errors are benign", sitting a few
+  thousand lines below the first: the same file already imports
+  `isMissingTableError` from `@objectstack/metadata/errors` and asks it in
+  `rethrowUnlessMetadataStoreUnprovisioned` (#5532), as do this package's
+  `SysMetadataRepository` (#4867) and `DatabaseLoader` (#5108).
+
+  A copy is wrong in both directions, and only one of them is loud:
+
+  - **SQLite** says `no such table: sys_metadata`, which the copy matched — by
+    luck of which driver the author was running.
+  - **PostgreSQL** says `relation "sys_metadata" does not exist` (SQLSTATE
+    `42P01`) and **MySQL/MariaDB** says `Table 'app.sys_metadata' doesn't exist`
+    (errno 1146). Neither matches the regex, so a perfectly healthy first boot on
+    either driver printed `[Protocol] DB hydration skipped: …` — a warning about
+    a working system that no operator can act on.
+  - Conversely, any driver phrasing a _different_ failure as "no such table" was
+    read as benign and swallowed without a line.
+
+  The seam now asks `isMissingTableError`, so the classification follows driver
+  `code` / `errno` / message / one step down the `cause` chain, and a driver quirk
+  is taught to the platform once. Observable change for operators: no spurious
+  first-boot warning on Postgres/MySQL, and a real failure that happens to be
+  worded like a missing table is no longer silently benign. The warning line also
+  reports non-`Error` rejections properly instead of printing `undefined`.
+
+  Not changed here: a non-benign read failure is still answered with a
+  `console.warn` plus `{ loaded: 0, errors: 0, invalid: 0 }`, so the return value
+  still cannot distinguish "the store holds no overlay rows" from "the store could
+  not be read" (ADR-0110 D3, on the boot side). That is a change to the method's
+  return contract and to its consumer in `ObjectQLPlugin.restoreMetadataFromDb`,
+  and is tracked separately as #5841 fact 2.
+
+- 288e5a4: fix(metadata-protocol): the ADR-0010 lock gate refuses an uncertain write instead of allowing it (#5706)
+
+  `getEffectiveLock` is the single source of truth for the ADR-0010 §3.3 lock
+  gate, and both of its callers are write-path admission — `assertLockAllowsWrite`
+  (save / publish / rollback) and `assertLockAllowsDelete`. Its overlay read was
+  wrapped in a bare `catch` that fell through to `lock: 'none'`.
+
+  `'none'` is not a neutral placeholder there. It is the verdict "the author
+  declared no protection", and `evaluateLockForWrite` / `evaluateLockForDelete`
+  turn it straight into "allow". So a `sys_metadata` read that **failed** became a
+  write that was **performed**, on an item whose overlay row declared it
+  protected. Measured before the fix, with the overlay row carrying `_lock` and
+  only the gate's own read rejecting: `saveMetaItem` returned `success: true`
+  after updating a `_lock: 'no-overlay'` item, and `deleteMetaItem` returned
+  `success: true` after deleting a `_lock: 'no-delete'` one — while the very same
+  rows, read successfully, produce `403 ITEM_LOCKED`. The audit trail did not
+  record the miscarriage either: the allowed path writes its ordinary
+  `outcome: 'allowed'` row, so nothing afterwards showed the write should have
+  been denied.
+
+  **Wire-visible change.** When the lock state cannot be read, `save`, `publish`,
+  `rollback` and `delete` now fail with `503` / `SERVICE_UNAVAILABLE` (the driver
+  error attached as `cause`) instead of proceeding as if the item were unlocked.
+  Refusing one uncertain write is the intended trade against performing one that
+  had to be refused. Callers that retry on 503 need no change; callers that
+  treated a successful save as proof the item was unlocked never had that
+  guarantee.
+
+  The discrimination reuses `rethrowUnlessMetadataStoreUnprovisioned`, introduced
+  in #5705 for this file's overlay reads, rather than inventing a second
+  predicate: an unprovisioned `sys_metadata` genuinely has no overlay row, so
+  `'none'` is the truth and first boot still saves normally; every other error is
+  an outage.
+
+  Unaffected, and covered by regression tests: artifact-level locks (answered from
+  the in-memory registry before the overlay read is reached), a genuine miss on a
+  healthy store (still allowed), and control-plane kernels (`environmentId`
+  undefined), which never enter either gate.
+
+- 1c625ca: metadata: `getDiagnosed` — a metadata read that FAILED stops arriving as "nobody declared this"
+
+  `MetadataManager.loadDiagnosed` computes the ADR-0110 D3 verdict (a MISS and an OUTAGE
+  are different facts with opposite security meanings) and `get()` discarded it two hops
+  later: `load()` kept only `.data`, `get()` turned that `null` into `undefined`. Every
+  consumer of `get()` therefore received one `undefined` for two opposite facts and could
+  not have told them apart even if it had wanted to.
+
+  **New read.** `MetadataManager.getDiagnosed(type, name)` returns
+  `{ data, degraded, errors }` — the registry-first counterpart of `loadDiagnosed`, declared
+  as an optional member of `IMetadataService`. A registry hit is never degraded (it
+  consulted no loader); a clean miss is never degraded (every loader answered).
+
+  **`get()` is unchanged — zero breaking.** Same signature, same answer, same behaviour for
+  every existing caller, including the microtask-level ordering `register()`'s watchers
+  depend on. Only callers that ASK for the verdict pay for it. Making `get()` throw on
+  `degraded` was deliberately not done: the boot path degrades on purpose.
+
+  **Consumers switched**, each with a disposition argued for its own context rather than one
+  blanket rule:
+
+  - `getMetaItem` / `getMetaItemCached` — a degraded MetadataService read with nothing in
+    the registry now raises `503 SERVICE_UNAVAILABLE` instead of falling through to
+    `404 RESOURCE_NOT_FOUND`. This is the half that made the existing `#5532` comment ("
+    reaching here now means a real miss") untrue.
+  - `getMetaItemLayered` — the `code` layer joins the rule its `overlay` layer already
+    followed. `code: null` is a positive claim, and `lockSource = code ?? overlay ?? {}`
+    derives from it, so an outage could render an item the packager locked
+    (`_lock: 'full'`) as `editable: true, deletable: true`.
+  - `ObjectQLPlugin`'s `object` metadata-event refresh — logs `warn` naming the consequence
+    (the registry keeps the previous definition; nothing retries) and the fix, instead of
+    `debug` "metadata service has no fresh body". `warn` and not `error` because the write
+    already landed; only a re-read failed.
+
+  Hosts whose `metadata` slot is a shim that predates `getDiagnosed` are read as
+  "not degraded" — exactly what they could express before — so their behaviour is unchanged.
+
+- e6db317: fix(metadata-protocol): 元数据存储读不到不再被讲成「这一项不存在」(#5532)
+
+  `sys_metadata` 整体不可达时,`GET /api/v1/meta/object/acct` 会回一个「不存在」——
+  真相是「读不到」。两个事实的处置方向完全相反(去建一个 / 去修后端),而 Studio、
+  Setup 在元数据库故障期就是照前者渲染的:每一个对象都显示成「不存在」。
+
+  根因在产出方:`getMetaItems` / `getMetaItem` 的四处 customization-overlay 读各自
+  裹着一个裸 `catch {}`,注释写着 "DB not available" 然后照 miss 处理。空值一路穿过
+  读链,每个消费方给它起了一个不同却同样错的名字:
+
+  - `getMetaItemCached` → `Metadata item <type>/<name> not found`
+  - `?state=draft` → `NO_DRAFT` / 404「没有待发布的草稿」(发布流程读作「没什么可发的」)
+  - `getMetaItems` → `items: []`「这个环境一个都没声明」
+
+  ADR-0110 D3 已经为这件事立过规矩:miss 与 outage 是两个不同的事实、安全含义相反。
+  #5108 按这条修掉了 `DatabaseLoader` 的复数读,#5089 修掉了 `listForIndex`;本次是
+  同一条规矩在协议自己的 overlay 读上,单数与复数一并覆盖。
+
+  **改了什么**
+
+  1. **区分按错误类型判定,不按异常猜。** 唯一良性的读失败是「`sys_metadata` 还没被
+     创建」——那时确实没有 overlay 行,落回 registry 就是真相,首次启动也不该爆炸。
+     判定走 `isMissingTableError`,与 `DatabaseLoader`(#5108)、本包
+     `SysMetadataRepository`(#4867)同一个谓词,一个驱动怪癖只教给平台一次。其余
+     一律视为故障。
+  2. **故障照实上报。** 上抛 `status: 503` / `code: SERVICE_UNAVAILABLE`
+     (`HttpStatusErrorCodeMap[503]`,ADR-0112 的标准目录码,不新造词汇),驱动原始
+     错误挂在 `cause` 上。REST 层现有的 #5437 / #5464 消毒与日志口原样接住:客户端拿
+     到 503 + code(文案按 5xx 规则 withheld),运维在日志里拿到完整的驱动报文。
+  3. **终末 not found 结构化。** 真 miss 现在带 `status: 404` /
+     `code: RESOURCE_NOT_FOUND`。
+
+  **wire 可见变化**(把错误答案改成对的答案):
+
+  | 场景             | 之前                                                            | 之后                                 |
+  | ---------------- | --------------------------------------------------------------- | ------------------------------------ |
+  | 元数据存储不可达 | `404`/`400`/`500` 说「不存在」「没有草稿」「什么都没声明」      | `503` + `SERVICE_UNAVAILABLE`,可重试 |
+  | 真的没有这一项   | `500` + `INTERNAL_ERROR`(#5489 之前是 `400` 且内部措辞逐字上线) | `404` + `RESOURCE_NOT_FOUND`         |
+
+  `sys_metadata` 尚未建表这一路径行为不变:仍旧落回 registry / MetadataService,
+  真查不到时回结构化 404。
+
+- da538b1: seed-loader: a pass-2 back-fill dropped for a missing source-record id is now reported, not silently discarded
+
+  `resolveDeferredUpdates()` looked the source record's internal id up in `insertedRecords`
+  and, when it was not there, ran off the end of an `if` with no `else`. Pass 2 had already
+  RESOLVED the target, and the back-fill then evaporated: no write, no entry in
+  `errors`/`allErrors` (so the load still reported `success: true`), no `errored`, and not
+  one log line. The only trace was the `referencesDeferred` the record booked in pass 1 and
+  never gave back — a dangling number with nothing in the result explaining it, while the
+  declared association stayed absent forever.
+
+  It now records the loss through `recordDeferredError` (→ `errors`/`allErrors` + `errored`,
+  so the load reports `success: false`) and logs it once at `error`, per the same objective
+  criterion applied in #4729/#4997 and the "Degradation log levels" rule. The two ways to
+  get here are worded differently because they are different failures: an EMPTY
+  `recordExternalId` — `externalIdKey` returns `''` when any component of a composite
+  externalId is blank — is the pure silent loss, where the row wrote perfectly, nothing else
+  in the load reports anything and the reference stays NULL forever; a real key that is
+  simply absent from the map means the source row never landed, and that write failure was
+  already reported at `error`, so this line points at it instead of restating it.
+
+  A load that hits this path previously returned `success: true` with clean counters and now
+  returns `success: false` with the loss counted — the seed data was always incomplete; it
+  just was not saying so.
+
+- 79822b5: fix(metadata-protocol): stop `promoteDraft`'s draft drain from swallowing every failure (#4981)
+
+  Publishing a draft is two writes: a transactional `put` that promotes the body onto
+  the active row, then a `delete` that drains the now-redundant `state='draft'` row.
+  The drain was guarded by a bare `catch {}` whose comment named exactly one cause —
+  "a concurrent publisher may have already drained the draft" — while its behaviour
+  covered **all** of them: connection drops, statement timeouts, missing privileges,
+  driver faults, `parentVersion` mismatches.
+
+  The result was a silent, self-perpetuating inconsistency. `publishDraft` returned
+  success, the active row was correct and durable, and a stale `state='draft'` row
+  stayed in `sys_metadata` holding the body that had just been published. Nothing
+  logged it and nothing retried it, so Studio/Setup kept reporting "unpublished
+  changes" for an artifact that had none, and the next publish of that artifact
+  promoted the same already-published body again — which overwrites the active row if
+  anything published or reverted in between.
+
+  **The drain now discriminates by cause.** `ConflictError` — the only error
+  `delete()` raises from its own pre-driver row lookup — stays silent, because both of
+  its arms are genuinely benign: `actualHead === null` is the concurrent-publisher
+  race the old comment described, and a differing head means a _newer_ draft was saved
+  while the publish was in flight, so the surviving row is real pending work that must
+  not be dropped. Every other failure is reported at `error` level (per the
+  `warn`-vs-`error` rule: the system keeps looking healthy while something it claims to
+  have cleaned up is still there), naming the orphaned artifact, the consequence, and
+  the remedy, with the original cause attached.
+
+  **`promoteDraft` still returns success, deliberately.** The drain runs _after_ the
+  `put` has committed, so throwing would misreport a durably successful publish as a
+  failure and invite the caller to retry — and a retried publish is precisely the
+  harmful path, because it re-promotes the stale draft. The failure is surfaced
+  without lying about the publish instead: alongside the log, the result carries a new
+  optional `draftDrainFailed` field (`{ ref, draftHash, cause }`, exported as
+  `DraftDrainFailure`) so callers can react without parsing logs. It is an additive
+  optional field on an existing result object — absent on every clean publish — so no
+  existing caller changes.
+
+  No protocol or spec shape changed. The drain seam is registered with
+  `pnpm check:durability-log-level` (as the named callee `dropPromotedDraftRow`) so
+  the catch cannot quietly go back to swallowing everything.
+
+- 15e61fb: fix(metadata-protocol): `publishPackageDrafts` 现在对 `api` draft 跑 ADR-0121 端点发布门 (#5206 step 2)
+
+  `protocol.publishPackageDrafts` 是 Studio「全部发布」的真实入径(ADR-0033 /
+  ADR-0067 D2)。在此之前,它唯一的按类型前置检查是对象命名空间前缀
+  (`validateObjectNamespacePrefix`,仅 `d.type === 'object'`),于是一条 `api`
+  draft **不经任何一道门**就被提升为 `active` —— 与 #5189 在
+  `MetadataManager.publishPackage` 上修掉的是同一形状、另一条路。
+
+  安全后果早已被 PR #5203 的装载期兜底挡住:端点匹配器在建索引时用同一个
+  `firstFailure` 重判每一条存量条目,没过门的被排除出索引并 `error` 点名。所以
+  这次修的是**拒绝得太晚**:ADR-0121 的原文是「publish 拒绝」,作者应当在
+  publish 当场拿到点名 key 的处方,而不是到装载期日志里才发现自己的端点在答
+  404。
+
+  **判据只有一份。** 本改动调用 `@objectstack/spec/api` 导出的
+  `validateApiEndpointDeclarations`(#5203 公开)—— 就是 stack schema 跑的那个
+  函数、`publishPackage` 跑的那个函数、装载期兜底跑的那个 `firstFailure`。拒绝
+  文案直接用门函数自己的消息(已包含端点名、越界的 key 和改法),本包不复述任何
+  一条「什么算可服务」的规则。
+
+  与 `publishPackage` 不同,这条路**有身份**:包的 `manifest.namespace` 本来就
+  为对象前缀规则读过了,所以这里跑的是**全量门**,命名空间门(ADR-0121 D1/D2)
+  包含在内。命名空间门**不**以「包声明了 namespace」为条件 —— 门函数自己的前置
+  判据(声明了 `apis:` 的 stack 必须显式声明 `manifest.namespace`)本身就是一条
+  判据,对「压根没有 namespace」的包跳过它,等于给最不可能过编译期的那批包留一
+  个洞。对象前缀规则对无 namespace 的包网开一面,是因为一个裸对象名只是命名气味;
+  一个无命名空间的端点是一个**无主 URL**。
+
+  **行为变化(用户可见)**:
+
+  - 一条 `api` draft 若违反端点门(最典型:ADR-0121 D6 —— `authRequired: false`
+    却没有 `rateLimit.enabled: true` 的预算),`publishPackageDrafts` 现在返回
+    `success: false` / `publishedCount: 0`,该条目进入 `failed[]`,`code`
+    为 `ENDPOINT_GATE`;body 连 `ApiEndpointSchema` 都不满足的,`code` 为
+    `ENDPOINT_SCHEMA`(解析是判定的前置,不是第六道门 —— 判不了的形状也服务不
+    了)。
+  - **失败粒度沿用既有语义,未发明新的批次语义**:与命名空间前缀违规完全一致,
+    这是一次**提升任何东西之前**的前置拒绝,整批不落地(`published: []`),同批
+    的健康 draft 保持 draft 态。这既是 ADR-0067 D2 的「一次 commit 不能落一半」,
+    也是 #5189 在另一条路上的同一姿势(`itemsPublished: 0`)。两类违规现在合并
+    在**同一份报告**里返回,作者一次往返就能看全。
+  - 判定范围是**本批被提升的 draft**,与紧邻它的对象前缀规则一致。与同包已
+    `active` 的端点撞车不在此拦截 —— 匹配器对全库重复声明有确定性裁决并 `error`
+    点名(`buildEndpointIndex`);把范围扩到整包 active 集合意味着「因为你没在发
+    布的东西而拒绝这次发布」,那是另一份契约,不是一个 bug 修复。
+
+  装载期兜底(#5203)原样保留,未移除也未削弱:publish 是**更早**的那道门,不是
+  最后那道门的替代品。
+
+  `api` 进 `DEFAULT_METADATA_TYPE_REGISTRY` / `BUILTIN_METADATA_TYPE_SCHEMAS`
+  (即 Studio 直写路径的 422)是 #5206 的第 1 步,拆在子单 #5271(spec 车道);
+  本改动**不依赖**它落地。
+
+- 72bd873: fix(metadata-protocol): 保存成功的回执不再一律自称 "customization overlay"
+
+  `saveMetaItem` 的成功 `message` 原本只有两种句式,都写死了 "customization
+  overlay"。但 `DEFAULT_METADATA_TYPE_REGISTRY` 里有一批类型声明
+  `supportsOverlay: false` 而按设计可以运行时写入(`object` / `field` / `hook` /
+  `seed` / `mapping` / `flow` / `action`),对它们的一次全新创建并没有覆盖任何
+  artifact,却也被回执成 "saved a customization overlay"。
+
+  判据不是 `supportsOverlay`,也不是 `allowOrgOverride`(spec 的 TSDoc 把这两件事
+  分得很清楚:前者是 loader 的合并能力,后者是运行时写入的许可),而是写路径**早已
+  算出**的 `isArtifactBacked` —— 也就是 `intent: 'override-artifact' |
+'runtime-only'` 的来源。回执现在只说这条已知事实,不新增任何读路径查询。
+
+  |                                 | FROM                                                                       | TO                                                  |
+  | :------------------------------ | :------------------------------------------------------------------------- | :-------------------------------------------------- |
+  | 覆盖了 code package 的 artifact | `Saved customization overlay (org=…, state=…) — type=…, name=… [seq=N]`    | 逐字不变                                            |
+  | 无 artifact 的运行时写入        | `Saved customization overlay (env-wide, state=…) — type=…, name=… [seq=N]` | `Saved <type> '<name>' (env-wide, state=…) [seq=N]` |
+
+  org 维度照旧在括号里(`org=<id>` / `env-wide`),`state=` 与 `[seq=N]` 两个分支都
+  保留,所以读取 `seq`(HMR 游标)或 `state` 的消费方不受影响;`message` 本身没有
+  任何消费方解析,仅作 toast 展示。
+
+  回执不区分「新建」与「更新既有 DB-only 行」:唯一可用的事实 `parentVersion ===
+null` 的作用域是 `(state, packageId)`,一个已有 active 行的首个 draft 也会读成
+  "没有父版本",据此写 `Created …` 只是把一句假话换成另一句假话。中性动词
+  "Saved" 如实,且不为一句文案发明新的查询。
+
+- dde9202: fix(metadata-protocol): 读路径 `_diagnostics` 保留 union 分支给出的真实拒绝理由 (#5598)
+
+  `computeMetadataDiagnostics` 给 `getMetaItems()` / `getMetaItem()` 服务出去的每份
+  文档挂 `_diagnostics` 信封,模块头写明它的用途是让 Studio 渲染 validity badge、
+  **内联字段错误**和治理看板。但它把 zod 的 `error.issues` 直接 `.map()` 成信封条目,
+  而 zod 会把一个失败 `z.union` 的**全部分支**折叠成一条顶层 issue —— `path` 是 `''`,
+  message 是字面量 `"Invalid input"`。`ViewMetadataSchema` 顶层本身就是 union
+  (`z.preprocess(stripViewConsoleDecorations, z.union([...]))`),所以库里**每一个**
+  有缺陷的 view 文档读出来都退化成这一条没有字段名的记录,内联字段错误无处可标。
+
+  这不只是"少了点信息",而是**同一份文档在两条路径上判决不一致**:#5364(PR #5596)
+  修好写路径之后,作者**保存**一个有缺陷的 view 能看到出错的键名,**打开**同一份已存
+  在库里的文档却仍然只得到一条 `Invalid input`。
+
+  改法是复用而不是再抄一份策略:读路径改调同包 #5596 已落地的
+  `zodIssuesToMetadataIssues`,分支选取口径(丢弃只报根部 KIND 不匹配的分支;报得最少
+  的分支胜出;`unrecognized_keys` 破平局;并列全出且有上限;嵌套 union 按绝对路径递归)
+  由该函数**单点定义**,读写两路径按构造一致。这是同一机制的第 5 个消费者
+  (#4971 / #5014 / #5341 / #5364 是前四个)。
+
+  对消费者是**纯增量**:union 自己那条记录仍然排在 `errors[0]`,只是后面跟上了解释它的
+  分支条目,所以任何读 `errors[0]` 的既有代码读到的还是同一条。没走 union 的普通字段级
+  拒绝(`path` / `message` / `code`)逐字节不变;spec 合法的文档仍然是 `{ valid: true }`,
+  展开不会凭空造出拒绝。
+
+- 5ab0842: refactor(metadata-protocol): 删除 `saveMetaItem` 里已不可达的 legacy raw-engine 写入分支 (#5264)
+
+  `saveMetaItem` 过去有两条持久化路径:repository 写入路径(追加
+  `sys_metadata_history`、发 watch 事件、带单调 `seq`),以及其后的 legacy
+  raw-engine 分支(直接 `engine.insert` / `engine.update` 写 `sys_metadata`,
+  没有 history 行、没有 watch 事件、没有 `seq`,回执形如
+  `Saved customization overlay (env-wide) — type=…`)。后者的进入条件是
+  `isOverlayAllowed(type) || isRuntimeCreateAllowed(type)` 为假。
+
+  **没有行为变化 —— 这条分支在运行时已经到不了。** #5086(PR #5263)把
+  code-only 类型的拒绝提到了同一方法更早的位置,并且不再以 `environmentId`
+  为条件:它抛错的判据与上面那个条件恰好互为反面,读的还是同一个规范化后的
+  类型键(`canonicalizeMetaRequestType` 在方法开头折叠单复数,两个标志读取器
+  内部又各自折叠一次)。`OS_METADATA_WRITABLE` 也不是缺口:在那里解锁一个
+  类型会让 `isOverlayAllowed` 为真,从而走回 repository 路径。因此凡是能走到
+  分叉点的写入,一律走 repository 路径。
+
+  保留 `useRepoPath` 的代价不是多几行代码,而是它是一份 grep 得到、读起来
+  像活代码的样板:照它推理会得出「`sys_metadata` 存在一个不写 history 的
+  合法写入口」——现在没有了。
+
+  `deleteMetaItem` 里结构对称的那条 legacy 分支**一行未动**:它在
+  control-plane kernel(`environmentId === undefined`)上删除 code-only 遗留行
+  时仍然可达且必要(#5263 特意没有收紧删除侧,因为删除是修复动作),该分支上
+  新增了说明它为何还活着的注释。
+
+- d275c10: fix(metadata-protocol): 元数据保存的 422 保留 union 分支处方,Studio 重新拿得到字段名 (#5364)
+
+  `saveMetaItem` 的 spec-conformance 检查在自己的注释里承诺 "structured Zod issues
+  so the Studio form can highlight the offending field"。顶层 `z.union` 让这句承诺
+  彻底落空:zod 把一个失败 union 的**所有**分支折叠成**一条**顶层 issue,`path` 是
+  空串、`message` 是字面量 `"Invalid input"`,而旧代码的 `parsed.error.issues.map(…)`
+  映射的正是这一条。
+
+  代价不是"文案不够好",而是**字段定位本身消失了**。`ViewMetadataSchema` 顶层就是一个
+  union(`view.zod.ts` 的 `z.preprocess(…, z.union([…]))`),所以**每一次** view 保存
+  失败都退化成:
+
+  ```json
+  [{ "path": "", "message": "Invalid input", "code": "invalid_union" }]
+  ```
+
+  一个字段名都没有到达作者,Studio 表单没有任何东西可以高亮;422 的摘要行也只是
+  `... failed spec validation: <root>: Invalid input`。被丢掉的分支里躺着的恰恰是
+  #4001 那批策展处方(点名真实键名的 unrecognized_keys)和带绝对路径、带合法枚举的
+  逐槽位判决。
+
+  现在这些分支被展开进 `issues[]`:union 自己那条**保留不动**(展开是严格叠加的,
+  今天读 `issues[0]` 的消费者不会少读到任何东西),后面跟上真正解释这次拒绝的分支,
+  路径按绝对路径拼好——分支 issue 的 `path` 是**相对于 union** 的,这是 #5014 付过
+  学费的坑。422 的 `message` 摘要行随之变得可读。
+
+  分支选择策略与已落地的两处**逐条一致**:丢弃只报根部 kind 不匹配的分支;报得最少
+  的分支胜出;`unrecognized_keys` 破平局;声明顺序决定其余;并列的全部输出(上限 3);
+  嵌套 union 递归展开(上限 3 层)。这是同一机制的**第三份**拷贝——`packages/spec`
+  的 `formatZodError`(#4971)只导出字符串渲染器,`packages/rest` 的
+  `zodIssuesToFields`(#5014)产出 ADR-0114 的 `{field, code}` 目录条目,而本处的信封
+  是 `{path, message, code}` 且 `code` 透传 zod 原码——形态不同,**判决必须相同**,
+  否则同一个错误会因为作者是从终端发布、还是 POST 数据 API、还是在 Studio 里保存,
+  拿到三套说法。
+
+  行为边界:合法的元数据照常保存,非法的元数据照常被 422 拒绝且不落库;变的只是
+  `issues[]` 从"一条无字段的 `Invalid input`"变成"那一条 + 真正解释它的分支"。
+
+- 1d29e6d: fix(metadata-protocol): a seed failure that is COUNTED as an error now logs at `error` (#4729)
+
+  `SeedLoaderService`'s pass-2 deferred back-fill carried a comment stating that a
+  failed back-fill "must be a reported, counted error, **never** a silent warning"
+  — and the line under it called `logger.warn`. The count was right (the failure
+  lands in `result.errors`, flips `success: false`) but the level contradicted it,
+  and that log line is the only trace a seed leaves in a host's console. `warn` is
+  the level #4420 proved nobody reads.
+
+  **What changed**
+
+  - The failed back-fill logs at **`error`**, and the line now owes what
+    AGENTS.md → "Degradation log levels" requires of one: the **consequence**
+    (`<object>.<field>` stays NULL on a named record, the row itself was seeded so
+    every row counter reads clean, the circular relationship is half-written) and
+    the **fix** (nothing retries it — repair the write error, which is either a
+    transient failure that outlasted the retry budget or a validation rule vetoing
+    the update, then re-run the seed).
+  - The rest of the file was audited against the same criterion — _is this failure
+    counted in the load's `errors` (i.e. does it make `success: false`)?_ Five more
+    sites answered yes while logging `warn`, and were raised to `error`: a failed
+    batch insert row, a record dropped because its `cel` expression could not
+    resolve, the two invalid-reference paths that DROP a reference field (the row
+    lands without its association and the row counters stay clean — framework#3932),
+    and the two write-failure catches on the sequential/update paths. The two
+    dropped-reference lines also gained the consequence and fix in the message.
+  - Deliberately left at `warn`, and now documented as audited: "Halting on first
+    error" (a control-flow notice about failures already reported at `error`), the
+    `NODE_ENV` scope warning (a functional, fail-open degradation), and the
+    roll-up-summary recompute (records _were_ written; whether a stale summary
+    column is the same class is #4998).
+  - The seam is now pinned by CI, not only by tests: the back-fill write was
+    extracted as `writeDeferredReference` and added — with `writeRecord` — to
+    `DURABILITY_CRITICAL_CALLEES` in `scripts/check-durability-degradation-log-level.mjs`,
+    so `pnpm check:durability-log-level` fails if either catch is ever quietened
+    again.
+
+  No API, schema or result-object change: the same errors are reported in
+  `SeedLoaderResult` exactly as before. What changed is the level and the wording
+  of what a seeding host sees in its log.
+
+- c5a5996: fix(seed-loader): a roll-up summary left stale by a seed is now loud and counted
+
+  The loader recovers a post-write roll-up summary recompute that exhausts its
+  retries (`ERR_SUMMARY_RECOMPUTE`), and that recovery is correct: the rows WERE
+  written, so re-writing them would duplicate them (framework#3147). What was
+  wrong was the rank of the consequence. A roll-up summary is a **persisted
+  derived column** on the parent record, so after this the database is internally
+  inconsistent — the detail rows say one thing and the column that summarizes them
+  says another — and nothing recomputes it until some later write happens to touch
+  the same parent, which after a seed may never happen.
+
+  The entire event used to be one `warn` line reading _"records were written
+  (summary values may be stale)"_. It named no object, counted nothing, and left
+  `success: true` with every row counter clean, so no operator could see which
+  aggregate was wrong and no caller could detect it at all
+  ([#4998](https://github.com/objectstack-ai/objectstack/issues/4998)).
+
+  **It now logs at `error`**, naming the seeded object and the exact stale column
+  (`account.total_billed`), stating the consequence (the summary and its detail
+  rows disagree, nothing self-heals, and the seed still reports success) and the
+  remedy (fix the recompute error and re-run the seed, or trigger any write on the
+  affected parent to force a recompute), with the original cause attached. This is
+  the AGENTS.md "Degradation log levels" rule (#4632): persisted state and runtime
+  state disagreeing while everything looks normal is `error`, not `warn`.
+
+  **And it is counted** — `SeedLoadResult.summariesStale` and
+  `SeedLoaderResult.summary.totalSummariesStale`, mirroring `referencesDropped` /
+  `totalReferencesDropped`, which exists for the same shape one layer down ("the
+  row was written, something derived from it was lost"). A log line is not
+  something a caller can branch on; these counters are.
+
+  `success` deliberately stays `true`. It answers _"did the rows land"_, and they
+  did — every consumer treats `success: false` as "the write failed", so flipping
+  it would hand the protocol seed-apply surface a `false` with an **empty** errors
+  array and fail package/marketplace installs that in fact wrote every row. The
+  counter carries the signal instead; a caller that wants to treat a stale
+  aggregate as fatal reads `summary.totalSummariesStale > 0`.
+
+  Both counters are additive with a `0` default, so an existing producer or
+  consumer of `SeedLoaderResult` is unaffected — a payload written before this
+  release still parses, with `0`.
+
+- 5ea8e1e: fix(metadata-protocol): a seed record dropped for an unresolvable reference now says so at `error` (#4997)
+
+  When a seed's `lookup` / `master_detail` / `user` reference could not be
+  resolved and no pass 2 would run (`multiPass: false`), the loader dropped the
+  **whole record** — the right call, since writing it would put the raw
+  natural-key string into the FK column or, on an upsert UPDATE, corrupt the row
+  already there. The drop was counted (`errored`) and reported
+  (`result.errors` → `success: false`), and the code comment above it claimed
+  "LOUD", but the branch made **no logger call at all**. On the console a seed
+  that silently dropped N records was indistinguishable from a clean one, and the
+  `packages/runtime` seed call sites that only `await` the load never look at
+  `result.success` — so the loss surfaced later as "the app installed but the data
+  isn't there".
+
+  That branch now logs at `error`, per AGENTS.md → "Degradation log levels"
+  (#4632): the line names the record (`<object>` record #i), the field, the target
+  `<object>.<field>` it could not find, and the **consequence** (the whole record
+  was not seeded — not merely the association), followed by all three **remedies**
+  — seed the target object first, enable `multiPass` so pass 2 back-fills the
+  reference, or fix the natural key in the seed data.
+
+  The same objective criterion (does the outcome enter `errors`/`allErrors`?)
+  found one more never-logged branch in the same file and aligned it: a **deferred
+  reference still unresolved after pass 2** was counted exactly like its sibling
+  whose back-fill _write_ fails — which has logged at `error` since #4729 — and
+  logged nowhere. It now reports that the row was seeded while the relationship is
+  permanently missing, and how to complete it.
+
+  The **dry-run** branch stays deliberately quiet and is pinned that way by test:
+  a dry run writes nothing, its caller is by definition reading the result object,
+  and an `error` line about a simulated outcome only trains readers to skim
+  `error`. No counters, result shapes or messages in `result.errors` changed —
+  this is console output that was missing, not a contract change.
+
+- dca25e1: fix(metadata-protocol): `SysMetadataRepository` 的 `event_seq` / `version` 不再从一次失败的读里凭空发号 —— 只有「表还没建」可以从 1 开始 (#4867)
+
+  `SysMetadataRepository.nextEventSeq()` 与 `nextItemVersion()` 各有一个同形的 `catch`,把读
+  `sys_metadata_history` 的**全部**失败折成同一个答案:
+
+  ```ts
+  } catch {
+    // Table not provisioned yet (fresh DB) — start at 1.
+    return 1;
+  }
+  ```
+
+  这是 #4825 刚在 `DatabaseLoader`(TSDoc 自称 legacy、非事务的那条路径)上修掉的形状,原样长在
+  **canonical 路径**上 —— #4825 正文把 `SysMetadataRepository` 称作「历史写入应当收敛过去的地方」。
+  而且这里有两个数字:
+
+  - **`event_seq`** —— 历史排序与 rollback 定位的依据。表里已有 N 行时,一次瞬时读失败(连接抖动、
+    超时、权限)让下一条拿到 `1`,与既有行撞号;
+  - **`version`** —— `nextItemVersion()` 的 TSDoc 明说它刻意从 history 取 MAX「so delete + recreate
+    continues incrementing instead of restarting at 1」。一次读失败正好把它**恢复成它明确要避免的那个
+    行为**:lineage 从 1 重启并与既有 lineage 撞号,而 `MetadataManager.rollback(type, name, version)`
+    与 `POST /api/v1/meta/:type/:name/rollback` 正是按这个数字定位快照 —— 撞号之后回滚可能落到另一条
+    记录的同号版本上。
+
+  关键危害与 #4825 相同,是「**落盘的字节是错的**」而不是「字节没落盘」:insert 成功、日志一行没有、
+  系统对外完全正常,重试不修、重启也不修。
+
+  **「在事务里」并不能挡住它。** 事务解决的是*并发*撞号;它对「从一次失败的读推导出来的数字」没有任何
+  意见,一个成功提交的事务照样把错号提交得同样持久。事务真正给出的是干净的补救:抛出去,整笔写入回滚,
+  而不是提交一个编造的号。
+
+  现在按**错误类型**判别,复用 #4825 落地的那套判别器(不另起一套):
+
+  - **良性的「表还没建」** —— 没有行,就没有可撞的号,`1` 确实是下一个号,静默返回,fresh DB 照常启动;
+  - **其余一切读失败** —— 按 AGENTS.md「Degradation log levels」以 `error` 上报**后果**(写入已被中止、
+    事务回滚、什么都没提交;若按旧行为发 `1` 会与既有行撞号,使版本顺序不可信、回滚目标可能指向另一条
+    记录的同号版本,且无人能发现、重启也修不回来)与**修复动作**(修数据源/驱动错误后重试写入),然后
+    **原样抛出**,让事务回滚。一次故障只说一次,恢复时补一条 `info`。
+
+  ### `@objectstack/metadata` 新增子路径导出 `@objectstack/metadata/errors`
+
+  判别器 `isMissingTableError()`(#4728/#4825 家族)此前是 `@objectstack/metadata` 的内部工具,而本次
+  消费者在另一个包。三个选项中选了「从现有归属地**显式导出**」:在 `metadata-protocol` 里复制一份会重建
+  #4825 刚消灭的双源问题(同一个问题两套「哪些驱动错误算良性」的词汇表,谁先学会一个驱动怪癖谁就先漂移);
+  下沉到公共依赖本轮不可行(`packages/spec` 冻结、`packages/types` 有并行改动),且本次导出并不妨碍维护者
+  之后再下沉。
+
+  新增的是一个**叶子子路径**而不是包入口导出:`@objectstack/metadata` 的根入口会拖进 manager、全部
+  loader 与其 YAML/文件系统依赖,只为一个 40 行谓词付这个重量,正是把下一个作者推回「复制一份」的原因。
+  `@objectstack/metadata/errors` 只 re-export 一个叶子模块,跨包依赖边因此仍是叶子边,也是将来下沉时
+  一个可 grep、可删除的单点。仅导出 `isMissingTableError`;同族的 `isSchemaAlreadyExistsError` 在包外
+  没有消费者,保持内部(导出一个无人 import 的符号是白许的承诺)。
+
+  无 API 破坏、无 schema 变更、无 `packages/spec` 改动。
+
+- 38f53a0: fix(metadata-protocol): `updateMany` classifies an id-less row as a caller error, matching `batchData`'s update branch (#5100)
+
+  `runUpdateManyLoop` lacked the `!record.id` guard #4793 gave `runBatchDataLoop`'s
+  update branch, so the two by-id update faces classified the same malformed row
+  differently: `VALIDATION_FAILED`/400 on batch, but on `updateMany` the row fell
+  through to the #5088 existence probe as `{ id: undefined }` and came back
+  `RECORD_NOT_FOUND`/404 with `undefined` interpolated into the message — a
+  request-shape error reported as a data-state one, with the row's fate left to
+  each driver's undefined-where-key handling.
+
+  Not reachable over REST (`UpdateManyRecordSchema` requires `id`, #3939) — the
+  change is observable only to in-process callers of the protocol method, whose
+  id-less rows now answer `VALIDATION_FAILED`/400 (`Record id is required for
+update`) before any engine round-trip, identically on both faces (#4620: one
+  classification per file, enforced by a cross-face parity test). `record.data`
+  handling is aligned to the batch branch's `record.data || {}` in the same
+  change.
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [c1e67e0]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [64cd010]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [533a0a4]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [b746aa0]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [3133cda]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c794f78]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [641363a]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [0f17114]
+- Updated dependencies [ecc61ab]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [db0d53c]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [06ffad3]
+- Updated dependencies [811c30c]
+- Updated dependencies [2b2175b]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [d4edb5d]
+- Updated dependencies [eb26126]
+- Updated dependencies [be59695]
+- Updated dependencies [b2e1057]
+- Updated dependencies [ec6fad8]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [58f3220]
+- Updated dependencies [07f1822]
+- Updated dependencies [729a43a]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [08f93bc]
+- Updated dependencies [d9971d3]
+- Updated dependencies [eb3e650]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [02dc076]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [123067c]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [5d3ced9]
+- Updated dependencies [4b50be4]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [461ccda]
+- Updated dependencies [5582e18]
+- Updated dependencies [58f3220]
+- Updated dependencies [f238970]
+- Updated dependencies [06fc07a]
+- Updated dependencies [61fde5e]
+- Updated dependencies [95b4f0d]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [46365ab]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [b5459bc]
+- Updated dependencies [1624f4a]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [c5adfe1]
+- Updated dependencies [26e1029]
+- Updated dependencies [2f1e2a5]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [b821b29]
+- Updated dependencies [af96af6]
+- Updated dependencies [089767f]
+- Updated dependencies [5b8f95b]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [73580e7]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [bf1edef]
+- Updated dependencies [7b005b4]
+- Updated dependencies [da1a64c]
+- Updated dependencies [5e3c83b]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ddd6650]
+- Updated dependencies [51a587d]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [dca25e1]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [20963e7]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [e92e2c3]
+- Updated dependencies [946a131]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/lint@17.0.0-rc.4
+  - @objectstack/types@17.0.0-rc.4
+  - @objectstack/core@17.0.0-rc.4
+  - @objectstack/metadata@17.0.0-rc.4
+  - @objectstack/formula@17.0.0-rc.4
+  - @objectstack/metadata-core@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Major Changes
diff --git a/packages/metadata-protocol/package.json b/packages/metadata-protocol/package.json
index 2c3d05b72c..7fc448ee1c 100644
--- a/packages/metadata-protocol/package.json
+++ b/packages/metadata-protocol/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/metadata-protocol",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "ObjectStack metadata management protocol: sys_metadata CRUD, draft/publish, locks, package ownership, diagnostics (ADR-0076).",
   "type": "module",
diff --git a/packages/metadata/CHANGELOG.md b/packages/metadata/CHANGELOG.md
index f018f17d0d..b0294eca6a 100644
--- a/packages/metadata/CHANGELOG.md
+++ b/packages/metadata/CHANGELOG.md
@@ -1,5 +1,794 @@
 # @objectstack/metadata
 
+## 17.0.0-rc.4
+
+### Minor Changes
+
+- ecc61ab: feat(metadata): 端点匹配器 —— `MetadataManager.matchEndpoint` 惰性索引实现 (#5089)
+
+  `IMetadataService.matchEndpoint?` 的契约在 #5080/#5097 落地(声明先行),本变更补上
+  `metadata` 槽位占位者 `MetadataManager` 的实现:把已声明的 `api` 元数据条目编成
+  **METHOD → 精确路径 → 端点** 的惰性索引,供 HTTP 分发器在「没有内建域认领这条路径」
+  与「回答语义 404」之间做一次查表。这是 #5040 端点执行器程序的 E2 单。
+
+  **结构性不可达,零行为变更。** 17.x 里没有任何东西会调用 `matchEndpoint`:挂载 seam
+  是 #5090 的面,而 publish/validate 对非空 `apis:` 仍然硬拒(#4936)。新代码在真实组合
+  里不暴露任何 HTTP 行为;测试直接驱动服务,这正是 #5040 设计选定的验收姿态。
+
+  实现要点(逐字实现契约文本,`packages/spec/src/contracts/metadata-service.ts`):
+
+  - **匹配维度**:`method` 大写规整后比较(请求动词大小写不敏感);`path` 去掉**一个**
+    尾斜杠后**整串精确**比较,两侧同规则。17.x 不做百分号解码、不做 Unicode 规整、
+    不做大小写折叠 —— 原串即键。词表(ADR-0121)未定义任何路径模板语法,因此
+    `params` **恒为 `{}`**;此处不发明只存在于实现里的方言。
+  - **答案是 parse 后的形状**:每条经 `ApiEndpointSchema.safeParse`,默认值已物化 ——
+    作者省略 `authRequired` 时消费方拿到的是 `true`,不可能把「缺省」误读为放行。
+  - **坏条目响亮缺席**:解析失败的存量条目被跳过并以 `error` 级点名(说明该路由将回 404
+    及如何修),绝不返回半合法形状,也绝不牵连同批的好条目。
+  - **重复声明确定性收敛**:两条条目声明同一 METHOD+path 时,`name` 字典序在前者保留
+    路由,被弃者连同规则一并 `error` 级点名 —— 不是静默 last-write-wins,每个节点、每次
+    启动的解析结果一致。
+  - **断存储抛错,不伪装 404**:`undefined` 只表示「无声明拥有这条路由」;读不到存储时
+    抛出(与 `loadDiagnosed` 的 miss/outage 之分同源,ADR-0110 D3),因为 miss 会变成
+    404,而故障不得伪装成 404。构建失败不缓存,下次调用重试。
+  - **失效**:挂在仓内既有机制上,不新造事件系统 —— `invalidateListCache('api')` 覆盖
+    全部本地写入(含 artifact 装载 / HMR 的 `{ notify: false }` 写入,这些按构造不经过
+    watcher),`subscribe('api', …)` 覆盖集群对端回放(它只经 `notifyWatchersLocal`)。
+    失效后下次调用整体重建。
+
+  `ApiEndpointSchema` 与 `packages/spec` 未做任何改动(词表冻结)。
+
+- c52e608: fix(metadata,spec): the endpoint publish gates now guard the metadata write path too (#5189, #5040 E7b)
+
+  #5111 (E7) hung the five per-endpoint `apis:` gates on
+  `ObjectStackDefinitionSchema`, which every path that parses a **stack** runs
+  through — `defineStack`, `os validate`, the lint scorer, artifact ingest,
+  `EnvironmentArtifactSchema.metadata`. #5189 proved a stored `api` item need
+  never have been part of a stack: `MetadataManager.publishPackage`, a direct
+  `metadata.register()` and a Studio metadata write each mint one item at a time
+  and saw no gate at all.
+
+  Three of the five gates degrade safely when bypassed — the executor answers a
+  structured 501 naming the item, and a path outside the `apps/<namespace>/`
+  carve-out simply matches nothing. **ADR-0121 D6 has no runtime counterpart**:
+  the runtime honours `authRequired: false` faithfully and `deriveBucketConfig`
+  returns `null` for a budget whose `enabled` is not `true`, so the bypass minted
+  an anonymous, zero-quota execution entry point — the exact shape D6 exists to
+  forbid.
+
+  Two doors now, both running the SAME gate function rather than a second copy of
+  the criteria:
+
+  - **Publish** — `MetadataManager.publishPackage` runs
+    `validateApiEndpointDeclarations` over the package's `api` items and fails
+    the publish, naming each endpoint and the key to fix, on the same
+    `validationErrors` surface it already uses. This pass is **not** governed by
+    `options.validate`: an opt-out on a security gate is the bypass this fixed.
+  - **Load** — the endpoint matcher's index build re-applies the _identity-free_
+    subset (supported subset, mapping, policy/D6) to every stored item. A
+    declaration that never passed publish is EXCLUDED from the index and named at
+    `error` level, so a bypassed endpoint answers 404 with a loud log instead of
+    answering anonymously and unmetered. The namespace and uniqueness gates are
+    deliberately not applied there — both need a stack identity a stored row does
+    not carry.
+
+  **New in `@objectstack/spec/api`** (the module was package-internal in #5111,
+  whose only consumer was one file away):
+  `validateApiEndpointDeclarations`, `identityFreeEndpointGateFailure`,
+  `EndpointGateIssue`, `EndpointGateIdentity`.
+
+  **New option — `publishPackage(id, { namespace })`.** `MetadataManager` indexes
+  items by `packageId` and carries no manifest, so it cannot prove a namespace on
+  its own and will **not** infer one from the items it is judging (an
+  author-supplied value would make the ADR-0121 D1/D2 carve-out gate vacuous).
+  Callers that hold the package manifest pass its explicit `manifest.namespace`;
+  without it the namespace gate fails and the package's `api` items do not
+  publish — which is the rule, not a limitation: a publish that cannot prove a
+  namespace must not mint a URL under one. Packages that declare no `api` items
+  are untouched.
+
+### Patch Changes
+
+- d21c001: feat(spec)!: declarative `apis:` publishes again — the blanket refusal narrows to per-endpoint publish gates, and declared endpoints go LIVE (#5111, #5040 E7)
+
+  ⚠️ **Read this as a security note, not a schema note.** Declarative endpoints
+  **execute** from protocol 17. Before this release the surface was inert end to
+  end — nothing mounted a declared `path`, no matcher existed, and every key
+  including `authRequired` parsed green and gated nothing — which is why #4936
+  refused a non-empty `apis:` outright. The #5040 E-series built the executor
+  (mount seam, endpoint matcher, policy keys, execution targets, mapping keys,
+  OpenAPI enrichment), so the refusal's premise is gone and keeping it would be
+  the lie in the other direction.
+
+  ## BREAKING — the refusal narrows, and what passes it is served
+
+  `apis: [ …endpoints… ]` no longer fails wholesale. Each entry is now gated
+  individually, and **an endpoint that passes the gate is mounted and answers
+  real requests as soon as the stack is published.**
+
+  **Before you upgrade, review every historical `apis:` block** — including any
+  you restored, generated from an older doc, or left in place because it was
+  known to do nothing. Pay particular attention to any entry that explicitly
+  declares **`authRequired: false`**: the schema default is `true`, so an
+  _omission_ is safe and needs no review, while an explicit `false` is the only
+  thing that opens **anonymous** access to that endpoint. ADR-0121 D6 now pairs
+  it with a mandatory armed rate limit — and "armed" means
+  `rateLimit: { enabled: true, … }`, because `enabled` defaults to `false`, so a
+  budget written without it meters nothing.
+
+  ## The gates, each rejecting with its own prescription
+
+  | gate                           | rejected shape                                                                                                                                                                                                                                                                  |
+  | ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+  | **namespace** (ADR-0121 D1/D2) | a `path` that is not `/api/v1/apps/<manifest.namespace>/<subpath>`, or a stack that declares `apis:` without an explicit `manifest.namespace` (no derivation from `manifest.id`)                                                                                                |
+  | **supported subset**           | `type: 'script'` / `'proxy'`; an `object_operation` missing `objectParams.object` or `.operation`; a `flow` with an empty `target`                                                                                                                                              |
+  | **mapping**                    | any `transform`; an unusable `source`/`target` path (empty, empty segment `a..b`, `__proto__`/`prototype`/`constructor`); two entries whose `target`s collide (same path, or one inside another); `inputMapping` on a `find`/`get`/`delete` operation, which never reads a body |
+  | **policy**                     | `authRequired: false` without `rateLimit.enabled === true`; an armed budget with `maxRequests`/`windowMs` ≤ 0; a negative `cacheTtl`; `cacheTtl` on a non-GET method                                                                                                            |
+  | **uniqueness**                 | two endpoints in one stack claiming the same METHOD + path (one trailing slash trimmed, the matcher's own rule)                                                                                                                                                                 |
+
+  **FROM → TO.** `path: '/api/v1/<anything>/thing'` →
+  `path: '/api/v1/apps/<manifest.namespace>/thing'`, with `manifest.namespace`
+  declared explicitly. `authRequired: false` → either delete the key (the safe
+  default `true` applies) or keep it **and** add
+  `rateLimit: { enabled: true, windowMs: 60000, maxRequests: 100 }`. Every other
+  key is unchanged: the `ApiEndpoint` vocabulary is frozen — this release adds,
+  removes and renames nothing on it. The gates are validation logic over the keys
+  that already existed.
+
+  The runtime keeps its own refusals for a declaration that reached the store
+  without passing publish (a direct `metadata.register()`), so the two ends agree:
+  what publish accepts is exactly what the executor serves.
+
+  `normalizeEndpointPath` is now exported from `@objectstack/spec/api` and is the
+  one canonical form of a declared path — the publish gate and the endpoint
+  matcher (`@objectstack/metadata`) read the same rule instead of each carrying a
+  copy, so a stack can never publish a duplicate the matcher would silently
+  resolve to a single winner.
+
+- 533a0a4: fix(metadata): 集群对端的元数据写入现在会失效本节点的 `listCache` / registry (#5109)
+
+  多节点部署下,节点 A 改一条 `view` / `permission` / `flow`,节点 B 收到
+  `metadata.changed` 广播后**只叫醒了 watcher,却没有失效自己的缓存**。
+  `attachClusterPubSub()` 的订阅回调此前只做一件事 —— `notifyWatchersLocal()`,
+  既不碰 `this.registry` 也不碰 `this.listCache`。后果是 B 上任何走 `list(type)`
+  的读在 `LIST_CACHE_TTL_MS`(30 秒)窗口内继续返回改动前的清单;更糟的是,被叫醒的
+  watcher(ObjectQL SchemaRegistry 桥、Studio HMR SSE)如果回头调 `list()` 重新拉取,
+  拉到的还是旧的 —— 一份「失效通知」附带着失效数据。单机部署完全无感,只有多节点才暴露。
+
+  这与该通道自己声明的用途相反(`ClusterMetadataChangedPayload`:"consumed by peers
+  to **invalidate their local caches**",另见 `content/docs/kernel/cluster.mdx` §6.2
+  与 `metadata-lifecycle.mdx`);现在实现与声明一致。
+
+  修法沿用同文件里 `applyRepoEvent()` 自 ADR-0008 PR-6 起就用对的那条路径,并把两条
+  「外部写入」缝(仓库 watch 循环、集群对端回放)收敛到同一个私有方法
+  `invalidateForForeignWrite(type, name)`:
+
+  - **删除而不预填。** 即便事件带着 body,也只删除 registry 条目而不写入 ——
+    那份 body 是别人那次写入的快照,可能已被后续写入取代,预填会与真实 head 竞态,
+    并要求我们去规范化一份自己没有加载过的定义。删除后 `get()` 自然穿透到 loader /
+    repository,也就是真相所在。
+  - **同步失效,先失效再通知。** 失效发生在收到消息的当拍(不在 `setImmediate` 内),
+    通知仍然延迟派发。`setImmediate` 的存在理由是不让**消费方的 watcher 回调**背压
+    pubsub 派发循环;而失效只是两次 `Map.delete`,不执行任何消费方代码,没有需要延迟的
+    东西——把它一起延迟只会留下「已收到广播、尚未失效」的读窗口,请求处理器里任何一个
+    `await` 都足以撞进去。先失效后通知也与本文件其他写入路径
+    (`register` / `unregister` / `applyRepoEvent`)一致,于是回头 `list()` 的 watcher
+    拿到的是写后清单。
+  - **无名事件只失效清单缓存。** `MetadataWatchEvent.name` 在 spec 里是可选的,无名事件
+    无法定位 registry 条目;此时不会把整个 type 的 registry 一并清掉 —— 那会驱逐
+    `registerInMemory()` 注册的、任何 loader 都无法恢复的代码态构件(如 `origin:'code'`
+    的 datasource)。
+
+  回环抑制(`originNode`)仍然先于失效判断,本节点自己的广播不会让自己白白重建缓存。
+
+- 3133cda: fix(metadata): `DatabaseLoader` 的读故障不再被吞成「什么都没声明」(#5108)
+
+  `DatabaseLoader` 的五个读方法此前都把**任何**存储异常 `catch {}` 成各自的空值 ——
+  `load` → `null`、`loadMany` → `[]`、`exists` → `false`、`stat` → `null`、
+  `list` → `[]`。于是 `sys_metadata` 所在库不可达时,`loadMany('permission')` 与
+  「这个环境一条 permission 都没声明」返回**完全一样的值**,而且异常是在 loader 内部
+  就被抹掉的:`MetadataManager` 那几个 `try/catch` 降级分支拿到的是一次「成功的空读」,
+  根本不会触发,整条链上没有任何一处会说出「读失败了」。
+
+  现在按**错误类型**判决(#4632 立的规矩,#4728 / #4825 已经在同一个文件里用过两次的
+  形状,判据复用现成的 `isMissingTableError`):
+
+  - 唯一良性的失败原因是 `sys_metadata` 尚未 provisioned —— 那时确实没有行,
+    「什么都没声明」就是事实,首次启动照旧返回空值、不报错、不缓存;
+  - 其余全部原因(连接断开、超时、权限不足、查询出错)意味着行还在、只是这次没读到,
+    一律把驱动原始异常**原样抛出**,由调用方决定降级姿态。判据保守:无法正面识别为
+    「表不存在」的错误一律当作真故障。
+
+  由此上层三个已有的机制第一次真的生效:
+
+  - `MetadataManager.list()` 的降级分支会真的进,并且**升级到 `error`**
+    (AGENTS.md「Degradation log levels」:系统看着正常、它声称掌握的清单其实是残缺的),
+    日志写明后果与修法,每次故障只说一次、恢复时再说一次;`list()` 仍然尽力返回可读
+    loader 的内容 —— 这个 best-effort 姿态是刻意保留的。兄弟方法
+    `MetadataManager.loadMany()` 的同一条缝走同一个判决,不让同一次故障在同一个文件里
+    报出两个级别;
+  - `MetadataManager.loadDiagnosed()`(ADR-0110 D3)对 `DatabaseLoader` 终于能报出
+    `degraded` / `errors`,而不是把 outage 报成 miss;
+  - `listForIndex()` / `matchEndpoint`(#5089)契约要求「读不到存储必须抛出,不得伪装成
+    miss(miss 会变成 404)」—— 这条此前对 `MemoryLoader` / `RemoteLoader` 有效、对
+    `DatabaseLoader` 无效,现在对真实的 datasource loader 也成立了。
+
+  **行为变化**:`MetadataManager.exists()` 与 `listNames()` 本来就没有 `try/catch`,
+  所以存储故障现在会从它们抛出,而不再静默答「不存在」/「空清单」。这正是本次修复要的
+  姿态 —— 可用性故障不是一次「没有」。
+
+- c794f78: fix(metadata): a known-partial `list()` result is cached as degraded, on a 2s TTL instead of 30s (#5184)
+
+  Since #5108 a loader that cannot read its store throws rather than answering
+  `[]`, so `MetadataManager.list()` catches, reports the outage once at `error`,
+  and keeps serving what the reachable loaders hold. That best-effort posture is
+  deliberate. What was not deliberate is what happened on the next line: the
+  known-short result went into `listCache` on the same 30s TTL as a complete read,
+  with nothing on the entry to say it was partial.
+
+  The consequences were all invisible from outside. That one `error` line covered a
+  **30s window in which the failing loader was never asked again** — no retry, no
+  second signal, the manager simply re-served a set it already knew was short. When
+  the store came back, nothing noticed for up to another 30s, so #5108's recovery
+  line (`reportLoaderReadRecovered`) arrived that late too. And because the entry
+  carried no marker, no consumer of the cache — including that once-only report —
+  could tell a partial answer from a complete one.
+
+  Not caching degraded reads at all was considered and rejected on evidence. The
+  `listCache` field comment records why the cache exists: security middleware
+  calling `list('permission')` from inside a user-initiated DB transaction, where
+  `DatabaseLoader`'s `engine.find('sys_metadata', …)` tries to take a second knex
+  connection while the transaction holds SQLite's only one, and knex waits out
+  `acquireConnectionTimeout` (60s). That hazard was re-verified against the current
+  driver stack and is still live — `DatabaseLoader._find()` still does not thread
+  the caller's transaction, `driver-sql` still models SQLite as a
+  single-connection pool (`activeTransactions`, `assertBareKnexSafe`, the latter a
+  dev/test guard that no-ops in production), and `plugin-audit` still threads the
+  transaction by hand for the same reason. Skipping the cache would have traded one
+  30s silent window for a fresh 60s stall per call.
+
+  So the entry is still cached, but as what it is:
+
+  - `listCache` entries carry a `degraded` flag, set when at least one loader threw
+    while the result was being assembled. It lives on the entry rather than in a
+    side table, so every reader can distinguish a complete answer from a partial
+    one; entries are read through a single `readCachedList()` helper that applies
+    the flag and its TTL in one place.
+  - A degraded entry expires after **2s** (`DEGRADED_LIST_CACHE_TTL_MS`) instead of
+    30s. The burst of repeated lookups inside one transaction is still absorbed —
+    those are milliseconds apart — while the window in which a known-short set is
+    served without re-asking anyone shrinks 15×, and recovery is noticed (and
+    logged) within seconds of the store healing.
+  - A complete read is unchanged: cached, not degraded, 30s TTL.
+  - The outage message now names the degraded TTL as the retry interval, since it
+    previously promised the 30s one.
+
+  Also closes a `declared ≠ enforced` defect in the same field's comment: it claimed
+  the cache kept "only positive (non-empty) hits or repeated hits with a stable miss
+  signature". No such condition ever existed in `cacheListResult()`. The comment now
+  describes the policy the code actually implements, and the behaviour it claims
+  (an empty complete read _is_ cached) is pinned by a test.
+
+  Internal caching policy only — no change to the `IMetadataService` contract or to
+  any public export.
+
+- 2b2175b: fix(metadata): an unreadable file is no longer announced as `data: null` (#5228)
+
+  `NodeMetadataManager.handleFileEvent()` — the chokidar handler behind
+  `watch: true` — wrapped its re-read in a `try/catch` that logged
+  "Failed to load changed file" and returned without announcing. That `catch` was
+  **unreachable for the failure it was written to catch**. `load()` is
+  `(await loadDiagnosed(...)).data`, and `loadDiagnosed` (ADR-0110 D3)
+  deliberately absorbs a loader throw: it records the message in `errors[]` and
+  answers `{ data: null, degraded: true }`. `FilesystemLoader.load()` does throw
+  on an unparseable file — the throw simply died one frame below the handler, so
+  the `catch` never ran and the `logger.error` inside it never printed once.
+
+  What went out instead was a watch event carrying `data: null`, which is the wire
+  shape of "this metadata legitimately holds nothing". A file the loader could not
+  read and a file the author had emptied reached every subscriber in exactly the
+  same shape — the miss/outage distinction ADR-0110 D3 exists to preserve, erased
+  at the one call site that had picked the variant which throws it away.
+
+  The handler now reads through `loadDiagnosed` and splits on `degraded`:
+
+  - **Degraded** (a loader threw and none answered — an unreadable or unparseable
+    file): take the road the dead `catch` meant to take. Log `filePath`, the
+    metadata type and name, and `loadDiagnosed`'s `errors[]`, and announce
+    nothing. A developer who breaks a metadata file now gets told; before, the
+    event claimed the definition had been emptied and nothing was logged.
+  - **Clean miss** (`data: null`, no loader threw — the file is gone or
+    legitimately empty): unchanged, announced exactly as before.
+  - **Deleted** events never read, so a deletion can never be degraded and is
+    always announced.
+
+  Cache invalidation is unaffected and deliberately runs **before** the read, so
+  the read's verdict can never decide whether the caches are dropped. #5218's
+  contract holds in full: an unreadable file is still a real change to the stored
+  set (`loadMany` skips it), so `listCache` and the `registry` entry still go, and
+  the `api` endpoint index still rebuilds — `invalidateListCache` is that index's
+  first invalidation seam (#5089), so suppressing the announcement costs it
+  nothing.
+
+  No in-repo subscriber loses invalidation or reload correctness: the endpoint
+  index is covered by the seam above, `ObjectQLPlugin`'s `subscribe('object', …)`
+  answers events by re-reading (an unreadable file yields nothing to re-read
+  either way), and the email-template bridge falls through `event.data ?? get(...)`
+  to the same empty result. One behaviour does change for the dev HMR/SSE stream:
+  a file left permanently unparseable no longer wakes the Studio, which keeps
+  showing the last known-good definition until the next event instead of watching
+  it vanish.
+
+- 729a43a: fix(metadata): 文件系统改动同样失效本节点的 `listCache`/`registry`,不再只叫醒 watcher (#5218)
+
+  `NodeMetadataManager.handleFileEvent()` 在 chokidar 报告 `add` / `change` /
+  `unlink` 之后只做两件事:重新 `load()` 一次文件内容,然后 `notifyWatchers()`。
+  它既不碰 `listCache` 也不碰 `registry` —— 而 `load()` 是纯读路径(它委托给
+  `loadDiagnosed`,后者只遍历 loader),两个缓存都不写。
+
+  后果是**同一个 manager 的两个读接口互相矛盾**。手改 `rootDir` 下的
+  `view/<name>.json` 之后:
+
+  - `get(type, name)` 是新的 —— 它穿透到 `FilesystemLoader`;
+  - `list(type)` 在 `LIST_CACHE_TTL_MS`(30 秒)窗口内继续返回改动前的清单 ——
+    REST `/api/v1/metadata/:type`、Studio 左栏、`listViews()` 等一切走 `list()`
+    的读都受影响。
+
+  更糟的是被这次事件叫醒的消费者(Studio HMR/SSE 流、ObjectQL SchemaRegistry
+  桥)正是通过回头拉 `list()` 来响应的,于是这次唤醒**递回了它自己刚刚宣告已失效
+  的那份数据**。
+
+  这与 #5109(集群对端写入不失效本节点缓存)是同一形状、不同触发源,因此复用该
+  修复落地的 `invalidateForForeignWrite(type, name)`(可见性由 `private` 放宽为
+  `protected`):文件改动正是「不是经由本 manager 写接口发生的写入」,没有任何东西
+  替它刷新过缓存,delete-而非-预填 的语义也正好对上 —— 穿透回 loader 读到的就是
+  文件的真相。
+
+  两点与基类其余写路径一致的约束:
+
+  - **先失效,再通知**(`register` / `unregister` / `applyRepoEvent` / 集群订阅者
+    都是这个次序),使 watcher 不可能同时观察到事件与事件前的缓存;
+  - **registry 条目一并删除**,不只是列表缓存。FS 加载的条目本来就不进 registry,
+    通常无可删;但当同名条目此前被 `register()` / `registerInMemory()` 写过时,
+    它在 `get()` 和 `list()` 中都会**遮蔽** loader,只删列表缓存会让那份陈旧副本
+    一直应答下去。
+
+  命中面主要是开发期:`MetadataPlugin` 默认 `watch: true`,在
+  `bootstrap: 'artifact-only'` 下被强制关闭,`standalone-stack` 显式传
+  `watch: false`。因此 artifact 模式的 `os dev` 与 standalone 不受影响,非 artifact
+  的默认 `MetadataPlugin` 装配受影响。
+
+  `type === 'api'` 的行为不变:端点索引此前已由 #5089 装的 `subscribe('api', …)`
+  那条缝覆盖,本次改动把 `invalidateListCache` 那条缝也接上,两条缝对称。
+  `EndpointMatcher.invalidate()` 是两次赋 `undefined`,重复失效幂等。
+
+- 95b4f0d: fix(metadata): `list()` reads are single-flight, so the "one loader hit per TTL window" promise finally holds for concurrent callers too (#5253)
+
+  `MetadataManager.list()` was a bare "read the cache → walk the loaders → write
+  the cache" sequence. The cache is written only once a read has **finished**, so
+  it absorbed the caller that arrived second in _time_ but never the caller that
+  arrived second in _flight_: every `list(type)` issued while the first read was
+  still walking the loaders missed, and each one walked every loader itself. The
+  `listCache` field comment states the guarantee the cache exists to provide —
+  "the loader is only hit once per TTL window" — and that guarantee held for
+  sequential callers only.
+
+  That is not a rounding error on the path the cache was built for. The comment
+  names it: security/permission middleware calling `list('permission')` on the
+  request path while `DatabaseLoader`'s read sits inside a transaction that holds
+  SQLite's only connection, waiting out knex's `acquireConnectionTimeout` (60s).
+  Every concurrent request arriving during those 60s used to burn its own 60s,
+  because nothing had been written to the cache yet. The everyday version is
+  milder but constant: cold start, and the small burst of concurrent `list()`
+  calls that follows every invalidation point — `register()` / `unregister()`, a
+  cluster peer's write (#5109), a filesystem change (#5218) — each repeated the
+  full loader walk.
+
+  Reads of one metadata type are now single-flight. A `list(type)` that finds a
+  read already running for that type joins it instead of starting a second
+  identical walk.
+
+  - **Sharers share the outcome — as an explicit contract, not an accident.**
+    Every caller joining an in-flight read receives that read's exact result,
+    including when a loader was unreadable and the answer is known-partial.
+    `list()` is the best-effort listing seam and does not throw (the strict
+    counterparts remain `listForIndex()` and `loadDiagnosed()`), so a lost loader
+    is not an error to fail over from — it is the answer, and re-running the read
+    privately for a joiner would walk the same loaders against the same outage in
+    the same window.
+  - **#5184's degraded judgment is unchanged and is not bypassed.** A shared read
+    that lost a loader is still memoized `degraded: true` on the 2s TTL, never
+    laundered onto the 30s healthy TTL by having been shared, and every sharer
+    received that same partial set.
+  - **A write landing mid-read wins.** `invalidateListCache()` now retracts the
+    in-flight read as well as the finished entry. The retracted read keeps running
+    for the callers already waiting on it — they asked before the write — but it
+    loses the right to memoize its pre-write answer, so that answer cannot outlive
+    the write it predates; and a caller arriving after the write starts a fresh
+    read rather than joining a pre-write one. That second half is #5219 / #5229's
+    ordering bar restated for concurrency: a consumer woken by a metadata change
+    must not observe the event and pre-event state together.
+  - The in-flight map is self-cleaning — an entry is dropped when its read
+    settles, by that read only, so a fresh read that replaced it keeps its slot.
+
+  Internal caching policy only — no change to the `IMetadataService` contract or to
+  any public export. Sequential callers behave exactly as before.
+
+- 1c625ca: metadata: `getDiagnosed` — a metadata read that FAILED stops arriving as "nobody declared this"
+
+  `MetadataManager.loadDiagnosed` computes the ADR-0110 D3 verdict (a MISS and an OUTAGE
+  are different facts with opposite security meanings) and `get()` discarded it two hops
+  later: `load()` kept only `.data`, `get()` turned that `null` into `undefined`. Every
+  consumer of `get()` therefore received one `undefined` for two opposite facts and could
+  not have told them apart even if it had wanted to.
+
+  **New read.** `MetadataManager.getDiagnosed(type, name)` returns
+  `{ data, degraded, errors }` — the registry-first counterpart of `loadDiagnosed`, declared
+  as an optional member of `IMetadataService`. A registry hit is never degraded (it
+  consulted no loader); a clean miss is never degraded (every loader answered).
+
+  **`get()` is unchanged — zero breaking.** Same signature, same answer, same behaviour for
+  every existing caller, including the microtask-level ordering `register()`'s watchers
+  depend on. Only callers that ASK for the verdict pay for it. Making `get()` throw on
+  `degraded` was deliberately not done: the boot path degrades on purpose.
+
+  **Consumers switched**, each with a disposition argued for its own context rather than one
+  blanket rule:
+
+  - `getMetaItem` / `getMetaItemCached` — a degraded MetadataService read with nothing in
+    the registry now raises `503 SERVICE_UNAVAILABLE` instead of falling through to
+    `404 RESOURCE_NOT_FOUND`. This is the half that made the existing `#5532` comment ("
+    reaching here now means a real miss") untrue.
+  - `getMetaItemLayered` — the `code` layer joins the rule its `overlay` layer already
+    followed. `code: null` is a positive claim, and `lockSource = code ?? overlay ?? {}`
+    derives from it, so an outage could render an item the packager locked
+    (`_lock: 'full'`) as `editable: true, deletable: true`.
+  - `ObjectQLPlugin`'s `object` metadata-event refresh — logs `warn` naming the consequence
+    (the registry keeps the previous definition; nothing retries) and the fix, instead of
+    `debug` "metadata service has no fresh body". `warn` and not `error` because the write
+    already landed; only a re-read failed.
+
+  Hosts whose `metadata` slot is a shim that predates `getDiagnosed` are read as
+  "not degraded" — exactly what they could express before — so their behaviour is unchanged.
+
+- b5459bc: fix(metadata): `capabilities.write` now means BOTH directions — a writable datasource loader must implement `delete()` (#5276)
+
+  `MetadataLoader` declared `save?` and no `delete`, so `capabilities.write` meant
+  two different things at the two ends of an item's life: to `register()` it meant
+  "persist into me", and to `unregister()` it guaranteed nothing at all.
+  `unregister()` duck-typed `delete` at the call site and, when a loader had none,
+  **silently skipped it** — then dropped the registry entry, invalidated the list
+  cache and announced a `deleted` event anyway. The caller (Studio/Setup, REST
+  DELETE, the CLI, a package teardown) was told the delete succeeded while the row
+  stayed in the loader's store, was read straight back out by the next
+  `list()`/`get()`, and survived every restart with nothing to retry it.
+
+  Two changes, both making the declaration binding instead of decorative:
+
+  - **`MetadataLoader` now declares `delete?(type: string, name: string): Promise<void>`.**
+    The capability is stated on the contract, next to `save?`, instead of being
+    guessed at by each caller. A loader implemented against the interface can now
+    see that the method exists.
+  - **`MetadataManager.registerLoader()` rejects the combination that cannot
+    honour it.** A loader declaring `protocol: 'datasource:'` **and**
+    `capabilities.write: true` **without** a `delete()` method is refused at
+    registration with an error naming the loader, the consequence, and both
+    repairs. `registerLoader()` is the sole writer of the loader map — the
+    constructor's `config.loaders` funnel through it — so the combination can no
+    longer reach the runtime and lose a deletion there.
+
+  **Does this affect you?** Only if you register a custom metadata loader that
+  declares `protocol: 'datasource:'` with `capabilities.write: true`. If it does
+  and has no `delete()`, registration now throws where it previously succeeded and
+  quietly discarded your deletions. Two ways to fix it, both stated in the error:
+
+  1. implement `async delete(type: string, name: string): Promise<void>` on the
+     loader, removing the item from its store (`DatabaseLoader` in this package is
+     the reference implementation); or
+  2. if the loader is genuinely read-only, declare `capabilities.write: false` — a
+     read-only `datasource:` loader registers without complaint and is never
+     written to in the first place.
+
+  Loaders on the other protocols (`file:`, `memory:`, `http:`, `s3:`) are
+  unaffected in either direction: `MetadataManager` never persists to them at
+  runtime, so it has no deletion of its own to take back, and they may declare
+  `capabilities.write` without a `delete()` exactly as before. The one
+  `datasource:` loader shipped in this package, `DatabaseLoader`, has always
+  implemented `delete()` and is unchanged.
+
+- 1624f4a: fix(metadata): `capabilities.write` now also binds `save()` — a writable datasource loader must implement both halves of the write (#5654)
+
+  #5276 (shipped in v17.0.0-rc) made `capabilities.write` binding on `delete()`:
+  a loader declaring `protocol: 'datasource:'` with `capabilities.write: true`
+  and no `delete()` is refused at registration, because `unregister()` used to
+  skip it silently and announce the deletion anyway. The gate stopped there, so
+  **one declaration was binding at one end of an item's life and decorative at
+  the other**.
+
+  `MetadataManager.register()` had the identical hole one direction over. Its
+  persistence loop read `loader.save &&` first, so a `datasource:` loader
+  declaring `capabilities.write: true` **without** a `save()` method was
+  **silently skipped** — no warn, no error. `register()` then wrote the in-memory
+  registry, invalidated the list cache, announced `created`/`updated` and notified
+  watchers, so the caller (Studio/Setup, REST PUT, the CLI, a package publish) was
+  told the write succeeded. The item read back correctly for the life of the
+  process and was **gone at the next restart**, with nothing to retry it — a
+  durability degradation that leaves the system looking entirely healthy.
+
+  `registerLoader()`'s gate (renamed `assertWritableLoaderContract`) now requires
+  **both** `save()` and `delete()` for that combination, and rejects with one
+  message naming which method is missing, the consequence, and both repairs.
+  `registerLoader()` is the sole writer of the loader map — the constructor's
+  `config.loaders` funnel through it — so the combination can no longer reach the
+  runtime and lose a write there. The `save` short-circuit inside `register()`
+  survives as defensive code whose unreachability is now guaranteed by
+  construction, exactly like `unregister()`'s.
+
+  **Does this affect you?** Only if you register a custom metadata loader that
+  declares `protocol: 'datasource:'` with `capabilities.write: true`. If it does
+  and has no `save()`, registration now throws where it previously succeeded and
+  quietly discarded your writes. Two ways to fix it, both stated in the error:
+
+  1. implement
+     `async save(type: string, name: string, data: any, options?: MetadataSaveOptions): Promise<MetadataSaveResult>`
+     on the loader, persisting the item into its store (`DatabaseLoader` in this
+     package is the reference implementation); or
+  2. if the loader is genuinely read-only, declare `capabilities.write: false` — a
+     read-only `datasource:` loader registers without complaint and is never
+     written to in the first place.
+
+  Loaders on the other protocols (`file:`, `memory:`, `http:`, `s3:`) are
+  unaffected: `MetadataManager` never persists to them at runtime, so they may
+  declare `capabilities.write` without a `save()`/`delete()` exactly as before.
+  The one `datasource:` loader shipped in this package, `DatabaseLoader`, has
+  always implemented both and is unchanged.
+
+- dca25e1: fix(metadata-protocol): `SysMetadataRepository` 的 `event_seq` / `version` 不再从一次失败的读里凭空发号 —— 只有「表还没建」可以从 1 开始 (#4867)
+
+  `SysMetadataRepository.nextEventSeq()` 与 `nextItemVersion()` 各有一个同形的 `catch`,把读
+  `sys_metadata_history` 的**全部**失败折成同一个答案:
+
+  ```ts
+  } catch {
+    // Table not provisioned yet (fresh DB) — start at 1.
+    return 1;
+  }
+  ```
+
+  这是 #4825 刚在 `DatabaseLoader`(TSDoc 自称 legacy、非事务的那条路径)上修掉的形状,原样长在
+  **canonical 路径**上 —— #4825 正文把 `SysMetadataRepository` 称作「历史写入应当收敛过去的地方」。
+  而且这里有两个数字:
+
+  - **`event_seq`** —— 历史排序与 rollback 定位的依据。表里已有 N 行时,一次瞬时读失败(连接抖动、
+    超时、权限)让下一条拿到 `1`,与既有行撞号;
+  - **`version`** —— `nextItemVersion()` 的 TSDoc 明说它刻意从 history 取 MAX「so delete + recreate
+    continues incrementing instead of restarting at 1」。一次读失败正好把它**恢复成它明确要避免的那个
+    行为**:lineage 从 1 重启并与既有 lineage 撞号,而 `MetadataManager.rollback(type, name, version)`
+    与 `POST /api/v1/meta/:type/:name/rollback` 正是按这个数字定位快照 —— 撞号之后回滚可能落到另一条
+    记录的同号版本上。
+
+  关键危害与 #4825 相同,是「**落盘的字节是错的**」而不是「字节没落盘」:insert 成功、日志一行没有、
+  系统对外完全正常,重试不修、重启也不修。
+
+  **「在事务里」并不能挡住它。** 事务解决的是*并发*撞号;它对「从一次失败的读推导出来的数字」没有任何
+  意见,一个成功提交的事务照样把错号提交得同样持久。事务真正给出的是干净的补救:抛出去,整笔写入回滚,
+  而不是提交一个编造的号。
+
+  现在按**错误类型**判别,复用 #4825 落地的那套判别器(不另起一套):
+
+  - **良性的「表还没建」** —— 没有行,就没有可撞的号,`1` 确实是下一个号,静默返回,fresh DB 照常启动;
+  - **其余一切读失败** —— 按 AGENTS.md「Degradation log levels」以 `error` 上报**后果**(写入已被中止、
+    事务回滚、什么都没提交;若按旧行为发 `1` 会与既有行撞号,使版本顺序不可信、回滚目标可能指向另一条
+    记录的同号版本,且无人能发现、重启也修不回来)与**修复动作**(修数据源/驱动错误后重试写入),然后
+    **原样抛出**,让事务回滚。一次故障只说一次,恢复时补一条 `info`。
+
+  ### `@objectstack/metadata` 新增子路径导出 `@objectstack/metadata/errors`
+
+  判别器 `isMissingTableError()`(#4728/#4825 家族)此前是 `@objectstack/metadata` 的内部工具,而本次
+  消费者在另一个包。三个选项中选了「从现有归属地**显式导出**」:在 `metadata-protocol` 里复制一份会重建
+  #4825 刚消灭的双源问题(同一个问题两套「哪些驱动错误算良性」的词汇表,谁先学会一个驱动怪癖谁就先漂移);
+  下沉到公共依赖本轮不可行(`packages/spec` 冻结、`packages/types` 有并行改动),且本次导出并不妨碍维护者
+  之后再下沉。
+
+  新增的是一个**叶子子路径**而不是包入口导出:`@objectstack/metadata` 的根入口会拖进 manager、全部
+  loader 与其 YAML/文件系统依赖,只为一个 40 行谓词付这个重量,正是把下一个作者推回「复制一份」的原因。
+  `@objectstack/metadata/errors` 只 re-export 一个叶子模块,跨包依赖边因此仍是叶子边,也是将来下沉时
+  一个可 grep、可删除的单点。仅导出 `isMissingTableError`;同族的 `isSchemaAlreadyExistsError` 在包外
+  没有消费者,保持内部(导出一个无人 import 的符号是白许的承诺)。
+
+  无 API 破坏、无 schema 变更、无 `packages/spec` 改动。
+
+- e92e2c3: fix(metadata): `unregister()` invalidates the list cache AFTER the storage delete lands (#5259)
+
+  `MetadataManager.unregister()` dropped the registry entry and called
+  `invalidateListCache(type)` **before** awaiting `loader.delete()`. Those two steps
+  are separated by a real await window — one DB round-trip per writable loader — and
+  inside it the manager held a state that exists nowhere else: **registry already
+  empty, loader not yet empty**. `list()` merges the two, so a read arriving in that
+  window missed the just-cleared cache, assembled the still-stored row into its
+  answer, and memoized it as a _complete_ read — the full 30s healthy TTL, because no
+  loader threw and #5184's 2s degraded TTL therefore never applied.
+
+  Nothing invalidated again once the delete landed (`notifyWatchers()` does not touch
+  `listCache`), so an item that was gone from storage kept being enumerated for up to
+  half a minute. `list()` is the enumeration seam behind `GET /api/v1/metadata/:type`,
+  the Studio left rail, sync/export and every consumer that decides existence from a
+  declared set — and `get()`, which never reads that cache, said the item was gone the
+  whole time. For a gating type (`permission`, `api`) the two faces of one manager
+  answered opposite questions about whether a declaration exists.
+
+  **Fixed by ordering, not by an extra invalidation.** `register()` never had this
+  defect because it writes the registry _first_ and the registry outranks every loader
+  in the merge, so its own save window already shows the post-write state. The
+  invariant is therefore not "invalidate early" but _invalidate last, once every store
+  already holds the announced state_. `unregister()` now deletes from storage first,
+  then drops the registry entry and invalidates with **nothing awaited between them**,
+  then publishes and announces — #5219's invalidate-before-notify discipline unchanged.
+  A `list()` racing the delete now either sees a coherent pre-delete state (the delete
+  has not landed and has not been announced — that answer is the truth) or the
+  post-delete state; it can no longer cache the pre-delete answer past the delete.
+
+  This composes with #5253's single-flight rather than duplicating it: a read still
+  _in flight_ when the delete lands cannot be reached by dropping `listCache` — it has
+  not written its entry yet and would write the pre-delete answer afterwards.
+  `invalidateListCache()` also retracts that read's `inflightListReads` registration,
+  so it resolves for the callers already waiting on it but loses the right to memoize,
+  while a caller arriving later starts a fresh read.
+
+  **A storage delete that fails is now loud.** It used to `logger.warn('Failed to
+delete …')` and continue. Per AGENTS.md "Degradation log levels" this is
+  durability/consistency degradation, not functional: `unregister()` resolves
+  normally, the caller is told the delete succeeded, and the surviving row is read
+  straight back out of storage by the very next `list()`/`get()` — permanently, since
+  nothing retries it. It now logs at `error`, once per un-deleted item, naming the
+  consequence and the fix. The registry entry is still dropped in that case,
+  deliberately: the loader still holds the row so the item is served either way, and
+  keeping the entry would only pin an in-memory copy on top of a stored row nobody
+  maintains — dropping it makes the next read fall through to storage, which is the
+  actual truth after a failed delete, and makes it visible immediately instead of at
+  the next restart.
+
+  No API change. `unregister()` still resolves rather than throwing when a loader
+  refuses the delete.
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [64cd010]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [b746aa0]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [db0d53c]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [08f93bc]
+- Updated dependencies [d9971d3]
+- Updated dependencies [eb3e650]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [02dc076]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [e98fb14]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [1b9a53b]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [46365ab]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [c5adfe1]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [51a587d]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [f104bab]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [946a131]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/types@17.0.0-rc.4
+  - @objectstack/core@17.0.0-rc.4
+  - @objectstack/platform-objects@17.0.0-rc.4
+  - @objectstack/metadata-core@17.0.0-rc.4
+  - @objectstack/metadata-fs@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Patch Changes
diff --git a/packages/metadata/package.json b/packages/metadata/package.json
index 20f8fccf4f..2b446c44fb 100644
--- a/packages/metadata/package.json
+++ b/packages/metadata/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/metadata",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "Metadata loading, saving, and persistence for ObjectStack",
   "type": "module",
diff --git a/packages/objectql/CHANGELOG.md b/packages/objectql/CHANGELOG.md
index da28d31a05..373750367b 100644
--- a/packages/objectql/CHANGELOG.md
+++ b/packages/objectql/CHANGELOG.md
@@ -1,5 +1,1702 @@
 # @objectstack/objectql
 
+## 17.0.0-rc.4
+
+### Minor Changes
+
+- 3905c00: feat(objectql)!: a predicate bulk write evaluates and fires after-hooks PER ROW (#5038)
+
+  The 2026-08-04 maintainer ruling on #4800 / #4862, recorded as ADR-0058's
+  bulk-write addendum: **a bulk write is N record changes**, so every record-scoped
+  declaration on it is evaluated per row — `record` = that row's state, `previous` =
+  that row's pre-write state. Validation predicates have worked this way since
+  #3106; hook `condition`s and the record-change flow triggers riding the same
+  lifecycle hooks now join them.
+
+  **What was broken.** A `multi: true` update reaches `driver.updateMany`, which
+  resolves an affected COUNT. The lifecycle hook fired **once**, `previous` was
+  never assigned (only the single-id branch fetched a prior row), and `record`
+  degraded to the write's bare payload. So the transition condition the docs, the
+  formula skill and ten showcase flows all teach —
+  `status == "done" && previous.status != "done"` — could not be evaluated on a
+  bulk write. Hook conditions rejected the write (#4775/#5037); record-change flow
+  triggers were **silent**, firing zero times or once for a record that did not
+  exist. A missing audit row is the one failure nobody goes looking for.
+
+  **What changed.** The engine's bulk `update` / `delete` branches now read the
+  matched row set **once** — the same `driver.find` #3106 already issues, with
+  "this object has after-hooks" added to its demand test — and dispatch
+  `afterUpdate` / `afterDelete` once per matched row, each on a context with the
+  **single-record shape**: `input.id` = the row, `previous` = its pre-image,
+  `result` = its state. That is #2922's batch-INSERT ruling restated, and it is why
+  this fix has no code in the consumers: `hook-wrappers`' `record`/`previous`
+  bindings, the record-change trigger's context builder and plugin-audit's diff all
+  read those same fields and became correct at the producer.
+
+  - **Per-row dispatch is uniform across after-hooks.** It is deliberately NOT
+    keyed on whether a condition mentions `previous` — the ruling rejected that as
+    a hidden rule that would make a hook's firing count depend on its condition
+    text.
+  - **`ctx.result` per row is the ROW**, composed as `row ⊕ payload` from the
+    pre-image already in hand, so the batch still costs one extra query, not one
+    per row. A bulk DELETE has no post-state: its per-row context sets no `result`,
+    and consumers fall back to `previous`.
+  - **`onError` needed no new meaning** — it governs a handler on a record-scoped
+    context, which is now what it always gets: `abort` fails the operation, `log`
+    swallows that row and the batch continues.
+  - **A ceiling, enforced as a refusal.** Past 10 000 matched rows a predicate
+    write against an object with after-hooks is rejected _before_ the driver call
+    (`ERR_BULK_PER_ROW_HOOK_LIMIT`), so nothing is written. It is never downgraded
+    to one dispatch for the batch — that would skip the hook for N-1 rows silently.
+
+  **Breaking for hook authors, in the direction the contract declares.** An
+  after-hook on an object that takes predicate writes now runs once per matched row
+  instead of once per batch: a notification hook sends N messages, a
+  cache-invalidation hook runs N times. Objects with no after-hooks are untouched
+  and pay for no extra read. The write's own contract is unchanged — a predicate
+  write still resolves the affected count and still publishes ONE aggregate
+  `data.records.updated` (#4639).
+
+  **`before*` hooks stay batch-scoped, and that is not a gap.** `beforeUpdate` /
+  `beforeDelete` fire once for the whole batch because they may still rewrite the
+  payload, and one `updateMany` carries one payload. #5037's `HookConditionError`
+  and its `limitation` discriminator therefore **survive, rescoped to that
+  dispatch** — with a message that no longer promises an expiry that has already
+  happened, names the phase as the reason, and points at the matching `after*`
+  event where the same condition evaluates per row as authored. It also now names a
+  record-change flow trigger as a real route: #5037 refused to, on measured
+  evidence that the trigger shared the same unbound `previous`; that fact changed.
+
+  Docs (`data-modeling/formulas.mdx`) and `skills/objectstack-formula` §5 are
+  updated to teach one transition shape for both write forms, with the `before*`
+  exception called out.
+
+- d8f65fe: feat(objectql): the dangling-reference audit stops skipping `readonly`
+  references and files them in their own `provenance` bucket (#4743)
+
+  `auditDanglingReferences` used to drop every `readonly` reference field before
+  reading a single row. That skip rested on two grounds, and #4556 removed one of
+  them: the platform no longer writes a NON-ID into a reference column
+  (`sys_metadata_history.recorded_by` stored the sentinel string `'system'`; it
+  stores `NULL` now). What the skip still covered afterwards was exactly one
+  family — the audit-provenance fields `created_by` / `updated_by` /
+  `organization_id` that `applySystemFields` injects, all `readonly: true`.
+
+  Those hold **genuine ids, and genuine ids dangle**: delete one user and every
+  row they ever created points `created_by` at a row that is gone. "Who did this"
+  failing to resolve is precisely the question an audit trail exists to answer,
+  so the remaining skip was blindness rather than economy. The audit now probes
+  them.
+
+  **They do not join `dangling`.** A deleted actor and a broken business foreign
+  key are different findings with different remedies (usually nothing to do vs.
+  re-seed the target or clear the link), and merging them would bury the second
+  under the first. Two new report keys carry the new class, mirroring the
+  unknown/absent split the report already makes everywhere else:
+
+  | Key                               | Means                                                                                     |
+  | :-------------------------------- | :---------------------------------------------------------------------------------------- |
+  | `provenance: DanglingReference[]` | a `readonly` provenance reference that resolves to nothing — same row shape as `dangling` |
+  | `provenanceUndetermined: number`  | a provenance reference whose target could not be probed at all                            |
+
+  Both are **additive and optional in the type**, exactly like `aborted`: an
+  existing consumer keeps compiling and keeps reading `dangling` with its meaning
+  unchanged (a link the model _declares_ is broken). Every report this module
+  produces sets both explicitly.
+
+  ⚠️ **Expect `provenance` to be large on the first run against an aged
+  database.** One deleted user dangles every row they ever touched. That number
+  is pre-existing state being reported for the first time — not damage the audit
+  caught being done, and not a regression introduced by looking at it.
+
+  For the same reason `provenance` **alone does not raise the summary warning**.
+  On a database of any age it is non-empty on every healthy run, and a line that
+  always fires is the #4747 broken alarm again — it would train its reader
+  straight past the run where `dangling` had something in it. The counts ride
+  along in the payload whenever the line fires for a real finding, and the
+  itemised rows are always in the returned report. `provenanceUndetermined` is
+  separate from `undetermined` for the same reason: on a stack that never
+  registers `sys_user`, every provenance value probes "cannot tell", and that is
+  a fact about which platform tables are mounted, not about the audited data.
+
+  Scan order gained a third tier to keep the change from costing the signal it
+  sits next to: security surface, then objects carrying a business reference,
+  then the provenance-only remainder. Admitting the family means nearly every
+  object now has an auditable field, so without the tier a bounded run would
+  spend its row budget on tables carrying only provenance and never reach the
+  business findings the budget was built for.
+
+  Part of #4743 (fact 2). The stale `assertReferencesResolve` comment in
+  `engine.ts` (fact 1) is deliberately untouched here.
+
+- afa6aa5: feat(objectql): export the delete-dispatch contract so test doubles can be pinned to it (#4550)
+
+  A test double that is **looser** than the implementation it replaces converts a
+  green suite into no suite at all — silently, and on exactly the paths a double
+  was introduced for, which are the paths that were hard to test, which are
+  usually where the contract is densest. #4434 is the worked example:
+  `DELETE /api/v1/sharing/rules/:idOrName` answered 500 for every rule and both
+  address forms it advertises, from the day it was written, while
+  `deleteRule drops rule + all its grants` asserted success against it the whole
+  time — against a fake engine whose `delete` accepted the one call shape
+  `ObjectQL.delete` refuses.
+
+  `ObjectQL.delete`'s dispatch decision now lives in one exported place instead of
+  being re-derived by every fake:
+
+  ```ts
+  import { assertEngineDeleteDispatch } from '@objectstack/objectql';
+
+  async delete(object: string, options?: any) {
+    assertEngineDeleteDispatch(options);   // refuses what a real server refuses
+    …
+  }
+  ```
+
+  New exports, all pure and side-effect free:
+
+  - `resolveEngineDeleteDispatch(options)` → `{ kind: 'by-id', id }` |
+    `{ kind: 'multi' }` | `{ kind: 'reject', message }` — what the engine will do
+    with this call, without doing it.
+  - `assertEngineDeleteDispatch(options)` — throws exactly what the engine throws
+    on `reject`, returns the dispatch otherwise. This is the line a fake engine's
+    `delete` opens with.
+  - `scalarDeleteId(options)` — the SCALAR `where.id` or `undefined`. The half a
+    hand-written mirror drops: `where: { id: { $in: [...] } }` looks like an id
+    and is a multi-row predicate, so the engine rejects it without `multi`.
+  - `ENGINE_DELETE_REJECT_MESSAGE`, `ENGINE_DELETE_DISPATCH_CASES` — the message
+    and the shared conformance case-set, the same role
+    `packages/spec/src/data/*-conformance.ts` plays for drivers.
+
+  `ObjectQL.delete` itself reads `resolveEngineDeleteDispatch`, so a double that
+  imports it cannot be looser than the engine, ever — that is the property, and
+  it is the one a hand-mirrored `if` can only have until somebody edits one side.
+  No runtime behaviour changes: the same three verdicts, over the same inputs,
+  proved case-by-case against the real engine in
+  `engine-delete-dispatch.test.ts`.
+
+  Repo-side, `pnpm check:engine-double-contract` (wired into `lint.yml`) finds all
+  39 fake ObjectQL engines in the repo, holds new ones to this predicate, and
+  keeps the 30 not yet converted in a measured, shrink-only baseline.
+
+- c7406b0: fix(objectql,driver-sql,driver-memory,driver-mongodb)!: `FilterArray` 在 engine 门下沉,四驱动的数组方言删除 (#5158 拍板 C 第 2 步)
+
+  `FilterArray` —— `['stage','=','won']`、`['and', […], […]]`、`[[…], […]]` —— 是**仅输入**的
+  授权糖。#5285 已在 spec 里把这件事写明(`data/filter.zod.ts`,`filter-array-declaration.test.ts`
+  钉住「被声明」且「`where` 不接受它」)。本次是拍板 C 的第 2 步:让**运行时**与那份声明一致。
+
+  ## 改了什么
+
+  进入运行时的门有两扇,过去只有一扇按契约读:
+
+  | 门                                                                                                | 改前                                                                                                                               | 改后                                                                                            |
+  | ------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
+  | **Door 1** —— 协议/HTTP 面(`metadata-protocol`)                                                   | `isFilterAST` → `parseFilterAST`,不可下沉的数组答 `400 INVALID_FILTER`                                                             | 不变                                                                                            |
+  | **Door 2** —— 进程内 engine 直调(`ObjectQL.find`/`findOne`/`count`/`aggregate`/`update`/`delete`) | 数组**原样**透传给驱动                                                                                                             | 走**同一条缝**:`isFilterAST` → `parseFilterAST` 下沉为 `FilterCondition`,不可下沉的数组响亮拒收 |
+  | 四驱动(`driver-sql`、继承它的 `driver-sqlite-wasm`、`driver-memory`、`driver-mongodb`)            | 各自带**第二套过滤器编译器**,包括一种**中缀**方言(`[condA, 'or', condB]`)—— 没有任何 schema 声明过它,`parseFilterAST` 也表达不了它 | 数组方言删除;数组到达驱动即 `INVALID_FILTER` / 400                                              |
+
+  一个查询两套编译器正是 ADR-0053 D-A1 禁止的分叉,而且它已经产生了真实的产品分叉:cloud 的
+  `RemoteTransport.buildWhereSQL` 自 cloud#1075 起对**同一输入**响亮拒收,`driver-sql` 却编译它。
+  删掉方言后两侧自然合流。
+
+  ## 授权面:零变化
+
+  `FilterBuilder`(`@objectstack/client`)产出的元组与 `['and', ...]` 组、React block 的
+  `filters` prop、wire 的 `$filter` 面、showcase 的授权点 —— **全部原样工作**,因为下沉正是
+  这些形状本来的用途。wire 契约逐字节不变(Door 1 的行为未改)。
+
+  ## ⚠️ 可观察的行为变更
+
+  1. **中缀连接不再被编译。** `where: [condA, 'or', condB]` 过去只有驱动认识,现在在 engine 门被拒收。
+     声明的写法是前缀组:`['or', condA, condB]` —— 语义相同,`parseFilterAST` 有它的下沉。
+  2. **`findOne({ where: [] })` 现在抛错。** `[]` 的含义**没有变**(仍是「无过滤」,`find`/`count`
+     照旧返回/计数全部行)。变的是 `findOne` 终于**看得见**这一点:未下沉的 `[]` 过去被
+     `requireFindOnePredicate` 当作「驱动自己去解释的表达式树」放行,于是 `limit: 1` 落在整张表上,
+     返回**任意一行** —— 正是 #4419 要挡的缺陷,活在 #4419 自己的守卫里面。
+  3. **不可下沉的数组在 engine 门拒收,不再由驱动拒收。** 形状与操作符词表相同(`isFilterAST` 同一套),
+     变的是消息来自调用点、带上调用方自己的值,以及明说「过滤器没有被应用,否则会返回**未过滤**的结果集」。
+  4. **驱动直调者(不经 engine)受影响。** `SqlDriver` / `InMemoryDriver` / `translateFilter` 是公开
+     导出;把数组 `where` 直接喂给它们的调用方需要改为先 `parseFilterAST(...)` 再传,或改走 ObjectQL。
+     注意 `QueryAST.where` 的 `FilterCondition` 是索引签名类型,数组对它是**可赋值**的 —— 类型层从未
+     挡住这个输入,所以拒收必须在运行时。
+  5. **`driver-mongodb` 的 `createdAt` → `created_at` 字段别名随方言一起消失。** 它只存在于数组路径
+     (`mapFieldName`,仅被已删除的 `translateComparison` 调用),对象路径从未应用过它。消费端别名按
+     AGENTS.md PD #12 是债务而非模式,故不再补回:请写声明的字段名 `created_at`。
+
+  ## 删除的代码面
+
+  - `SqlDriver.applyFilters` 的数组遍历分支,及其比较发射器 `protected applyAstComparison`(约 220 行)
+  - `InMemoryDriver.convertToMongoQuery` 的 legacy array 分支(约 62 行)
+  - `driver-mongodb` `mongodb-filter.ts` 的 `translateArrayFilter` / `translateComparison` / `mapFieldName`(约 140 行)
+  - `driver-sqlite-wasm` 无自有实现,随 `SqlDriver` 继承变更
+
+  `[]` 在每一层的读法**都不变**:engine 删键、`parseFilterAST([])` 为 `undefined`、三个驱动都提前返回。
+
+- 5d3ced9: fix(objectql,lint)!: a `json_schema` validation rule's `format` keyword is now ENFORCED — records that passed before can start failing (#5029)
+
+  > **⚠️ BEHAVIOUR CHANGE ON DEPLOYED DATA — READ BEFORE UPGRADING.** A `format`
+  > keyword inside a `json_schema` validation rule used to enforce **nothing**.
+  > It now enforces. If any deployed object carries such a rule, writes that
+  > succeeded on the previous version can be **rejected** after this upgrade —
+  > including writes from flows, seeds, imports and integrations, not just the UI.
+  > Nothing about the metadata changed; the runtime simply started honouring what
+  > the metadata always said. See "Before you upgrade" below.
+
+  ## What was broken
+
+  `packages/objectql/src/validation/rule-validator.ts` built its shared ajv as
+  `new Ajv({ allErrors: true, strict: false })` and stopped there. In ajv 8 the
+  `format` keyword is **not built in** — it ships in the separate `ajv-formats`
+  package — and under `strict: false` an unregistered format is not an error: ajv
+  logs one line at compile time and **drops the keyword**.
+
+  So this rule:
+
+  ```ts
+  {
+    type: 'json_schema',
+    name: 'support_config_shape',
+    field: 'support_config',
+    message: 'Support config is invalid.',
+    schema: {
+      type: 'object',
+      properties: { email: { type: 'string', format: 'email' } },
+      required: ['email'],
+    },
+  }
+  ```
+
+  compiled fine, ran on **every** write, enforced `type` and `required` — and
+  enforced **nothing at all** for `format`. `{ email: 'not-an-email' }` was
+  accepted, for every record, forever. The only signal was a stderr line at
+  compile time naming no rule and no object.
+
+  This is the #4649 / #4762 family one level in, and the partial failure is what
+  made it nasty: the rule visibly rejects a bad `type` / missing `required`
+  payload in dev, so it reads as _working_ while the `format` half never fires.
+  `format` is also one of the most reached-for JSON Schema keywords (`email`,
+  `uri`, `uuid`, `date`, `date-time`, `ipv4`), so this was not an exotic corner —
+  and it is exactly the shape an AI writing metadata reaches for first.
+
+  ## What changed
+
+  - **`@objectstack/objectql`** now depends on `ajv-formats` and registers it on
+    the shared instance (`addFormats(ajv)`). The **default (full)** format set is
+    used deliberately: `fast` mode trades correctness for speed on precisely the
+    formats authors reach for most, and a format that "mostly" matches is the same
+    declared ≠ enforced defect with a smaller hole.
+  - **`@objectstack/lint`** — the #4762 publish gate
+    (`validate-rule-compilability.ts`) compiles every `json_schema` rule with the
+    SAME ajv environment the runtime uses, on purpose, so it registers the same
+    plugin. This is not cosmetic parity: `ajv-formats` also installs the
+    `formatMinimum` / `formatMaximum` keywords, so a gate without it treats them
+    as unknown keywords (`strict: false` ⇒ silently ignored) and would publish a
+    schema the runtime then refuses to compile — a rule that passes review and
+    enforces nothing, which is the failure that gate exists to prevent. The parity
+    test now reads the plugin registration out of the runtime's source, so the two
+    cannot drift apart silently.
+
+  **Authoring is unchanged.** `format` stays a legal, publishable JSON Schema
+  keyword; the publish gate does not refuse it (option 2 on #5029 was considered
+  and rejected — refusing standard JSON Schema would push authors into private
+  spellings). What changed is only that the declaration is now true.
+
+  ## Before you upgrade
+
+  1. Find the rules at risk: any `object.validations[]` entry with
+     `type: 'json_schema'` whose `schema` contains a `format` key, at any depth
+     (including inside `$defs` / `$ref` and a `conditional`'s `then` /
+     `otherwise` branch).
+  2. For each, audit the existing column against that format. Rows already stored
+     are **not** re-validated — nothing is rejected retroactively, and no
+     migration runs — but the **next write that touches the field** is checked,
+     which includes an unrelated PATCH that merely resends the JSON blob.
+  3. If a format was aspirational rather than real, remove that `format` key (or
+     relax it) _before_ upgrading. Deleting the keyword is now a meaningful,
+     visible act rather than a no-op.
+
+  ## Known limitation, recorded deliberately
+
+  A **misspelled** format name is still ignored. `format: 'emial'` compiles under
+  `strict: false` — ajv logs `unknown format "emial" ignored` and drops it — in
+  both the runtime and the publish gate, so a typo still enforces nothing. That
+  behaviour is unchanged here and pinned by test in both packages, so it is a
+  known boundary rather than an oversight; closing it is an authoring-time
+  decision of its own and is tracked separately.
+
+- 7c2f7dd: fix(objectql,service-queue): a `lifecycle` settings override can no longer undercut a consumer's retention floor (#5195)
+
+  ADR-0057 P4 lets an operator override any object's retention window per
+  environment and per tenant through the `lifecycle` settings namespace. Until now
+  the only validation on that override was **does it parse** — and a retention
+  window is not only the operator's business: other code can depend on the rows
+  still being there.
+
+  `sys_job_queue` is the worked example. `DbQueueAdapter` deduplicates publishes by
+  comparing a terminal row's `created_at` against its idempotency window, so the
+  dedup check only means anything while that row still exists; #5179 made the
+  ordering an invariant by refusing, at construction, an idempotency window longer
+  than the object's **declared** retention. A settings override the constructor
+  cannot see walks straight around it:
+
+  ```jsonc
+  // lifecycle → retention_overrides
+  { "sys_job_queue": { "maxAge": "1h" } }
+  ```
+
+  completed rows are reaped an hour after they are written, publish keeps
+  deduplicating against 24h, and duplicate deliveries resume **with nothing in any
+  log**.
+
+  **New: retention floors.** A consumer may now declare, at runtime, the shortest
+  window its own contract survives:
+
+  ```ts
+  lifecycle.registerRetentionFloor("sys_job_queue", {
+    policy: "retention", // or 'ttl'
+    minWindowMs: 24 * 60 * 60 * 1000,
+    declaredBy: "com.objectstack.service.queue",
+    consequence: "…what silently breaks below it",
+    remedy: "…the settings change that makes an override legal",
+  });
+  ```
+
+  - An override below the floor — **global or tenant-scoped** — is **rejected**,
+    and the declared window keeps running. Not clamped to the floor: clamping
+    would enforce a third number written in neither the declaration nor the
+    settings, and that number would move whenever an unrelated package changed
+    its floor. Rejection has exactly one fallback, the declaration, which is
+    already how an unparseable override resolves.
+  - The rejection is `error`-level and carries both the consequence and the fix,
+    because what it prevents leaves the system looking entirely healthy. It is
+    also on the sweep report as `LifecycleSweepReport.floorViolations` — machine-
+    readable, every sweep.
+  - A **declared** window below a registered floor is reported the same way and
+    still enforced: refusing to reap would trade a broken consumer contract for
+    the unbounded table #5179 just closed.
+  - Objects with no registered floor are completely unaffected — P4 overrides
+    behave exactly as before.
+
+  Floors are runtime wiring, not spec surface (the same call ADR-0057's reap-guard
+  amendment makes), plus a reason of their own: the queue's floor **is**
+  `DbQueueAdapterOptions.idempotencyWindowMs`, a per-kernel construction option, so
+  a static key on the object's `lifecycle` block could only ever be a second copy
+  of it that drifts. No `packages/spec` change.
+
+  `QueueServicePlugin` registers `sys_job_queue`'s floor on `kernel:ready`,
+  carrying the window the adapter was actually constructed with — so a non-default
+  `db.idempotencyWindowMs` is covered too. The ordering is now enforced from both
+  sides: the constructor rejects a too-long `idempotencyWindowMs`, the floor
+  rejects a too-short `maxAge`.
+
+  New exports from `@objectstack/objectql`: `LifecycleRetentionFloor`,
+  `LifecycleFloorViolation`, plus `LifecycleService.registerRetentionFloor()`.
+  `LifecycleLoggerLike` gained an optional `error()` (absent ⇒ falls back to
+  `warn`), and `LifecycleSweepReport` gained `floorViolations`.
+
+- 5b8f95b: fix(objectql,lint): enforce parent-scoped `readonlyWhen` on the server (#4889)
+
+  `readonlyWhen: P\`parent.status == 'paid'\``— the documented "once the header
+invoice is Paid, its lines are frozen" lock — was enforced **only in the client
+grid**. The server-side strip bound`record`and`previous`and had no`parent`at all, so every parent-scoped predicate faulted, took the fail-open branch, and
+the write landed anyway. On the reference app that meant one`PATCH` rewrote the
+  quantity and unit price of a settled invoice's line: HTTP 200, value persisted,
+  the grid still drawing the cell read-only. ADR-0057 D10 puts enforcement on the
+  server and makes the client courtesy; here only the courtesy layer enforced.
+
+  **`parent` is now bound on the write path.** For a detail object — one declaring
+  exactly one `master_detail` relationship — the engine resolves the master record
+  and binds it as `parent` before the strip runs, on both the single-id and the
+  bulk (`multi: true`) update paths. A repointing write is judged against the
+  master it _lands on_, not the one it leaves. The read is gated on the payload
+  actually touching a parent-scoped predicate (decided from the parsed CEL AST, so
+  a field named `parent_id` costs nothing), and the bulk path batch-reads the
+  distinct headers in one query rather than one per row.
+
+  **An unbindable scope no longer waives the lock.** A `readonlyWhen` that names a
+  root the operation could not bind now resolves to **locked** — the field is
+  stripped — instead of "not locked". "The platform could not check this" must not
+  mean "allowed" on a field the author declared frozen. This is deliberately the
+  narrowest possible carve-out from the fail-open policy the strip has always had:
+  a predicate that is merely _broken_ on the record (undeclared key, `null`
+  ordering overload, parse error, engine throw) still fails open exactly as
+  before, and `requiredWhen` / option `visibleWhen` are untouched. Recorded as an
+  addendum to ADR-0058's D5 fail-policy matrix, alongside the same narrowing
+  already made for validation predicates (#4649) and hook conditions (#4775).
+
+  **And the runtime branch is a backstop, not the plan.** `objectstack compile`
+  now **rejects** a `parent`-scoped `readonlyWhen` on an object that declares no
+  `master_detail` relationship, or two of them (where the metadata does not say
+  which one is "the parent" and picking by declaration order would make a
+  data-integrity lock depend on field ordering). The common authoring mistake is
+  caught where it is cheap to fix, so it never reaches a runtime that has to judge
+  it — declared, not guessed.
+
+  No metadata changes are required: an app whose parent-scoped locks were already
+  correct simply starts having them enforced. If you authored one on an object
+  with no single master, the build now names it.
+
+- 441d79f: fix(objectql): 同一 object 的多个 reap guard 现在按交集组合,后注册者不再静默顶掉前者 (#5535)
+
+  `LifecycleService.registerReapGuard(object, guard)` 此前是一行 `set()`,契约写明
+  「One guard per object (last registration wins)」,而注册表是 `private`、无探针、
+  覆盖时也不打日志。两点合起来:同一 object 上的**第二个注册方静默解除第一个**,且
+  **无从察觉**。
+
+  这在 reap guard 这个座位上格外危险,因为 guard 的语义不是「投票」而是**回执**——
+  「外部副作用已经做完,这行现在可以删了」。`sys_file` 的 guard 做的正是字节回收:
+  先 `storage.delete(row.key)`,失败则 veto 把行留到下一轮(行是字节的唯一指针,
+  先删行就永久泄漏)。任何第二个消费者在 `sys_file` 上注册,这段字节回收会被**整体
+  解除**:行照删、字节泄漏、零日志。而 ADR-0057 §3.3 的 amendment 恰恰把「domain
+  callback」认定为 guard 的合法形态,第二个注册方是被 ADR 鼓励出来的,不是假想。
+
+  **新契约:交集组合。** 一个 object 可以有多个 guard,注册**追加**而非替换;只有
+  **全部** guard 都确认的 id 才进删除集,任一 veto 即保留、由下一轮 sweep 重试。这与
+  单 guard 时的语义完全兼容(现有五条单 guard 回归全部原样通过),也与同文件
+  `registerRetentionFloor` 的「每个注册方都保留发言权,最严者胜」同构。
+
+  写 guard 时值得知道的两点:
+
+  - **guard 按注册顺序执行,但只会被问到「前面的 guard 已经确认过」的行。** 这是
+    刻意的:被问到即意味着「到目前为止所有人都同意这行可以删」,于是 guard 不会
+    为一行别人正要保留的记录做不可逆的清理(否则就会出现「行还在、字节已删」或
+    「行还在、索引已删」)。删除集本身与注册顺序无关。
+  - **guard 抛异常的处置不变**:异常上抛到 `sweep()` 的 per-object handler,该
+    object 本轮一行不删(erroring guard 永不 fail open 进删除)。同一批里更早的
+    guard 已经做掉的清理由下一轮 sweep 重试,而不会在无人完成确认的批次上兑现成
+    一次删除。
+
+  重复注册**同一个函数引用**是 no-op(重跑 wiring,不是第二份意见):与自己求交集
+  不改变任何结果,却会让它的外部清理在每批上跑两遍。
+
+  无需调用方改动:`service-storage` 的两个注册方(`sys_file` / `sys_upload_session`)
+  一行未改,行为逐条不变。本单落地即解除 #4672(知识插件走 reap-guard 去索引化)的
+  Blocked-by——它可以直接在 `sys_file` 上追加注册,而不必担心顶掉字节回收。
+
+- 23dba62: feat(spec,objectql): `strictReadonlyWrites` —— 让调用点选择「被剥离即响亮失败」(#5126)
+
+  写路径上的 readonly 剥离一直是**静默**的:调用方送来的只读字段被丢掉,写入照常提交并返回成功,该列保持原值。#4903(PR #5123)把这件事修得**可发现**(一条说清后果与出路的 WARN + `onFieldsDropped` 机器可读信号),但没能补上「出路」本身 —— 一个宁可让写入失败也不接受丢列的调用方(cron / 服务端插件)无处表达这个意图,因为选项键必须先落在 `packages/spec`。
+
+  本次按维护者裁定的 **B 方案**补上这一半:
+
+  - **`@objectstack/spec`**:`WriteObservabilityOptions`(`contracts/data-engine.ts`,`onFieldsDropped` 所在的**进程内** TS 契约)新增 `strictReadonlyWrites?: boolean`,默认关闭;`ERROR_CODE_LEDGER` 在 `@objectstack/objectql` 名下登记 `ERR_READONLY_FIELD_REJECTED`。
+  - **`@objectstack/objectql`**:`update` 在剥离接缝处兑现该语义 —— 置位且确有字段将被剥离时,在**任何驱动调用之前**抛出 `ReadonlyFieldRejectedError`(新导出,`code = 'ERR_READONLY_FIELD_REJECTED'`),因此**什么都不写**:不只是被拒字段,连本可存活的字段也不落库。单条与 bulk 两条路径同此。
+
+  三点值得单独说明:
+
+  - **默认行为零变化。** 不传(或传 `false`)时,剥离、`onFieldsDropped` 事件、提交结果与此前完全一致。这是一个 per-call 的选择加入项。
+  - **覆盖两种剥离原因。** 静态 `readonly`(#2948,仅对非 system 调用方生效)与 `readonlyWhen` 判定为真(#3042,对**所有**调用方生效,含 `isSystem`)。只覆盖前者会让本特性对它最想服务的调用方 —— 已声明 `isSystem: true` 的可信 cron —— 近乎失效:它恰恰豁免了静态剥离,却仍会静默丢掉被 `readonlyWhen` 锁住的列。两种原因累积进**同一个**异常,`fields` 是全量并集,`drops` 保留按原因的明细。
+  - **strict 是进程内语义,不跨 RPC / VDE 边界。** 它挂在 TS 契约而非可序列化的 `EngineUpdateOptionsSchema` 上,因此 REST / wire body **设不了**它:远程调用方既拿不到 `onFieldsDropped` 也拿不到 strict,其写入仍是「剥离后提交」。这是刻意的 —— 把写入拒绝开关放进客户端可填的袋子等于在安全相邻路径上开新攻击面(即被否掉的 A 方案)。契约测试钉住了这条边界。
+
+### Patch Changes
+
+- c497d26: fix(objectql): `autonumber` 是运行时拥有的字段,写路径不再接受调用者提交的单号 (#5503)
+
+  `autonumber` 的值一直被文档声明为运行时所有 —— `applyAutonumbers` 的注释写着
+  "the runtime owns the value, not the client",两个记录校验器也正是因此在 insert
+  与 update 上都豁免了 `required` 检查。缺的是另一半:**没有任何一层写路径阻止客户端
+  自己填这个值**。于是一个普通的 REST 调用者可以:
+
+  - `POST /data/:object` 携带显式单号 → 原样落库,序列被绕过;
+  - `PATCH /data/:object/:id` 携带该字段 → 200 且改写落库,业务单号被篡改。
+
+  这与已修复的 #4447(`created_at` 可被普通 PATCH 伪造)是同一缺陷族。区别在于:
+  声明了 `readonly: true` 的字段早已被 #2948 / #3043 的剥离机制保护,而 `autonumber`
+  字段身上根本没有这个标记,剥离循环从它旁边直接走过去了。
+
+  **修法:在引擎/校验层把 `type: 'autonumber'` 视为隐含 readonly,insert 与 update
+  同权。** 非 system 上下文提交的单号,在派发给任何驱动之前就被剥离:
+
+  - **UPDATE** —— `stripReadonlyFields`(`packages/objectql`)的判定从"作者声明的
+    `readonly: true`"扩展为"作者声明的 **或** 运行时拥有的字段类型"
+    (`isRuntimeOwnedField`,当前恰好只有 `autonumber`)。单行更新与 `multi` 批量更新
+    共用这一个剥离点,因此两条路径同时被覆盖。
+  - **INSERT** —— 引擎新增一个更窄的 `stripRuntimeOwnedFields`,只剥离运行时拥有的
+    字段。它**不**接管作者声明的 `readonly` 在 insert 上的语义:那条防线按 #3413 的
+    设计留在 DataProtocol 入口(#3043),因为 create 确实可能合法地写入只读列,而直接
+    调用 `engine.insert` 的可信内部写入者(身份预置、元数据仓库、事件游标)必须不受影响。
+    单号没有这种两可性 —— 谁都不该在 create 时自带单号。
+
+  剥离发生在引擎里、派发之前,这正是修复**与驱动无关**的原因:声明
+  `supports.autonumber === true` 的 SQL 驱动(持久序列)拿到的行里根本没有这个键,
+  所以它的序列必然胜出 —— 没有任何驱动需要改动一行代码。测试直接断言递交给
+  `driver.create` 的负载,而不是打补丁到驱动上。
+
+  **豁免语义保持不变**,与 update 侧原有的白名单完全一致:
+
+  - `isSystem` 写入(seed 回放、迁移、内部预置)整体跳过剥离;
+  - `preserveAudit`(#3493)的"历史数据导入"仍可写入原始单号 —— 把遗留系统的历史
+    单号迁移进来正是这个白名单存在的业务场景,而 `autonumber` 属于作者声明的业务字段
+    (`system !== true`),恰好落在 `isPreservableUnderAudit` 允许的范围内;
+  - `beforeInsert` / `beforeUpdate` 钩子计算出的值不受影响 —— 只有**调用者提交**的键
+    才是剥离候选。
+
+  **这是一次静默剥离,所以它被上报而不是被吞掉。** 引擎 insert 路径上的
+  `onFieldsDropped`(#3407)此前只是为了与 `update()` 对称而存在、从不触发,并留了一
+  句"若 insert 将来出现静默剥离,必须在剥离点接上监听器"——现在正是那个剥离点。
+  事件沿用既有的 `readonly` 原因码(对调用者而言,隐含只读与声明只读被丢弃的理由完全
+  相同,不值得为一个没有消费者会区分的差别在 `packages/spec` 里分叉词表)。
+  `createManyData` 与 `insertManyData` 也补上了监听器转发:后者保持**逐行精度**——
+  引擎事件是整批的并集,但剥离只会移除**行自身提交过**的键,因此可以准确归属回具体行。
+  导入器优先走的正是 `insertManyData` 这条部分成功路径。
+
+  **与 `strictReadonlyWrites`(#5126 / #5610)叠加。** 该开关是"剥离即拒绝"的进程内出路,
+  本次改动使它自然覆盖单号,两条路径同权:
+
+  - **UPDATE 无需新代码** —— autonumber 限肢走的正是 `stripReadonlyFields` →
+    `reportDroppedFields` → `assertNoStrictDrops` 这条 #5126 已经铺好的接缝,因此 strict
+    开启时,调用者提交的单号与声明 `readonly` 的字段一样被拒绝,整笔写入不落库;
+  - **INSERT 需要接上** —— #5126 当时把该开关在 insert 上留作惰性,并写下条件:"insert
+    一旦有了剥离,两个成员就在那个剥离点一起接上"。本次正是那个剥离点,于是
+    `onFieldsDropped` 与 `strictReadonlyWrites` 一并兑现:默认剥离+上报,strict 开启则在
+    任何驱动调用之前抛 `ERR_READONLY_FIELD_REJECTED`,且**监听器不触发**(被拒绝的写入
+    并未完成,这是 #5126 自己的设计要点)。
+
+  接缝处**没有新增任何策略**:#5126 明确写着 strict "不引入第二套策略,它只是把既有策略
+  报出来",且"剥离拿不走的字段也不会被拒绝"。照此逐字适用,`isSystem` 与 `preserveAudit`
+  两个豁免在 strict 下依旧被接受(它们根本不会走到剥离分支)。
+
+  `ReadonlyFieldRejectedError` 新增可选的 `operation`(默认 `'update'`,#5126 的 UPDATE
+  文案逐字节不变):动词与补救办法确实因操作而异 —— INSERT 的拒绝必然关于运行时拥有的值,
+  其合法写入者是 `isSystem` 与历史导入 `preserveAudit`,而 `readonlyWhen` 在 create 上
+  根本锁不住任何东西。
+
+  **升级影响。** 普通(非历史)导入若把遗留单号列映射到 `autonumber` 字段,该值现在会
+  被丢弃并改由序列发号,同时在响应的 `droppedFields` 里上报、在服务端日志里留下一条
+  带补救办法的 `warn`。要保留原始单号,请把导入标记为历史导入
+  (`treat_as_historical` → `preserveAudit`),这与 #3493 为只读业务字段确立的划分一致。
+
+  `packages/spec` 未改动:`autonumber` builder 是否应当直接注入 `readonly: true` 是
+  spec 层的独立议题,与这条引擎侧防线不冲突。
+
+- bbdbf28: fix(metadata-protocol,objectql): a boot that could not read `sys_metadata` says so at `error`, instead of reporting "no persisted metadata" at debug (#5897)
+
+  `loadMetaFromDb` — the boot step that hydrates `sys_metadata` overlay rows into
+  the SchemaRegistry — returned `{ loaded, errors, invalid }`, and no field in
+  that shape could express **"this hydration never read the store"**. An
+  unreachable database and a genuinely empty one both answered `loaded: 0`.
+
+  Its only production consumer, `ObjectQLPlugin.restoreMetadataFromDb`, therefore
+  had nothing to branch on: its single branch chose between two log lines, and
+  the "nothing came back" side was
+  `logger.debug('No persisted metadata found in database')`. So a kernel that
+  could not read a word of its persisted metadata stated at **debug** level that
+  there was none, and went on to report ready.
+
+  What that costs is not hypothetical — it is written into the plugin's own
+  Phase 2 comment. With the registry empty, `registry.getObject` answers "not
+  declared" where the truth is "we could not look": unknown-column query guards,
+  hooks and relationships silently degrade, and overlay objects get neither a
+  synced table nor a metadata bridge. This is ADR-0110 D3 (an outage is not a
+  miss) on the boot side, after the same rule landed for `DatabaseLoader`
+  (#5108), `listForIndex` (#5089) and the overlay reads (#5532 / #5707).
+
+  **What changed**
+
+  - `loadMetaFromDb` returns `storeUnavailable: boolean`, set on exactly the
+    branch that already prints `[Protocol] DB hydration skipped` — a read that
+    failed for a reason `isMissingTableError` does _not_ call benign. A store
+    that has merely not been provisioned yet (first boot, before migrations)
+    keeps `storeUnavailable: false`, because `loaded: 0` genuinely is the truth
+    there (#5841).
+  - `restoreMetadataFromDb` reads it and logs at **`error`**, naming the
+    consequence (nothing was restored, the kernel keeps reporting healthy, and
+    which capabilities silently degrade) and the fix (check the datasource behind
+    `sys_metadata` — connection, credentials, table existence — then restart).
+    Per AGENTS.md "Degradation log levels": persisted state and runtime state
+    disagreeing while the system still looks healthy is the `error` class. An
+    empty-but-readable store keeps its quiet debug line, so first boots do not
+    start emitting durability errors.
+
+  **Not changed**: control flow. Boot still degrades and continues — refusing to
+  boot on an unreadable overlay store would turn a transient outage into an
+  outright one. What changes is that the degradation is now distinguishable from
+  health, and reported as such.
+
+  **Impact on duck-typed `ProtocolWithDbRestore` implementers**: none required.
+  `ObjectQLPlugin` matches the `protocol` service structurally, and the new field
+  is declared **optional** on its side of the contract, exactly as `invalid`
+  already is. A shim that predates the field keeps type-checking and is read as
+  "not an outage" — the only verdict it was able to express before — so its
+  behaviour is byte-for-byte what it was. The trade-off is deliberate and worth
+  naming: an optional field cannot _force_ a third-party shim to start reporting
+  outages, so such a shim stays as silent as it is today. Requiring the field
+  would have made that impossible to ignore at the cost of breaking every
+  external implementer for a bit only one in-repo producer sets; the in-repo
+  producer (`ObjectStackProtocolImplementation`) declares and returns it
+  **required**, so the path that actually runs in every ObjectStack kernel is
+  fully covered.
+
+- 4335497: fix(objectql): a bulk write blocked by a `previous` hook condition is told it is a VERSION limit, not an authoring mistake (#5037)
+
+  #4775 made an unevaluable hook `condition` abort the operation, and #4861 gave
+  the predicate-bulk-write case its own sentence instead of a raw
+  `Unknown variable: previous`. What that sentence still said was
+  _"rewrite the condition without `previous`, or target the write at one record"_ —
+  written before the maintainer's 2026-08-04 ruling on #4800/#4862, and wrong in
+  its most important claim. The ruling settled the contract: **on a bulk write,
+  after-hooks and record-change flow triggers evaluate and fire per row** (recorded
+  as an ADR-0058 addendum, implemented by #5038). The author's transition condition
+  is legitimate; the engine is what is behind. Telling them to drop `previous` was
+  advising a silent semantic change — a transition ("just became done") becomes a
+  state test ("is done"), which fires on every row that was already done.
+
+  The rejection now says what is actually true:
+
+  - it names the batch and why there is no single prior record to bind, as before;
+  - it states this is a **current-version limitation**, cites the per-row contract
+    (ADR-0058 addendum, #4800/#4862) and the issue that retires the rejection
+    (#5038);
+  - it leads with the route that works today — target the write at one record, and
+    the same condition evaluates as authored — and prices the rewrite instead of
+    recommending it;
+  - it still refuses to point at a record-change flow trigger as a way out, which
+    remains verified rather than assumed: that trigger binds the same lifecycle
+    hooks and receives the same unbound `previous` on a bulk write (#4862).
+
+  **Machine-readable, so a caller never parses the prose.** `HookConditionError`
+  gains `limitation?: 'bulk_write_previous_unbound' |
+'bulk_write_stored_state_unavailable'` (exported as `HookConditionLimitation`)
+  alongside the existing `predicateBulkWrite` flag. It is deliberately _not_ named
+  `code`: ADR-0112 makes `error.code` a closed wire vocabulary
+  (`StandardErrorCode` ∪ `ERROR_CODE_LEDGER`) and `rest-server.ts` promotes a
+  thrown error's `.code` onto the response envelope, so a `.code` here would mint
+  an unregistered wire code as a side effect. A code that needs to travel goes
+  through the ledger as a decision.
+
+  **"Does this condition read `previous`" is now read off the parsed CEL AST**
+  (`collectCelRootIdentifiers`, the utility #4972's build gate already uses),
+  computed once at wrap time, with the old fault-text check kept as a fallback.
+  The diagnosis no longer depends on cel-js's wording, and it stays correct when
+  the evaluator faults on some other key the same condition reads.
+  `record.previous_status` is not a `previous` reference — the AST reports roots,
+  not member names — so it keeps the declared-field diagnosis, whose remedy is the
+  right one there.
+
+  Unchanged, and pinned by tests: single-record writes (bound `previous`, condition
+  evaluates, handler runs), bulk writes whose conditions do not name `previous`,
+  the plain undeclared-key typo report on a bulk write, and fail-loud itself — the
+  write still fails. Nothing here is an exemption; it is the same rejection with a
+  diagnosis attached.
+
+- 1b49eaf: fix(objectql,spec): app-declared `capabilities` reach the registry with package provenance (#5870, #4967 Part 2)
+
+  An authorization capability a package DEFINES (`defineCapability` →
+  `stack.capabilities`, ADR-0066 D1) never acquired registry provenance, so a
+  declaration that did not repeat its owner by hand was **declared but never
+  enforced**.
+
+  **FROM.** `ObjectQL.registerApp()` decomposes a manifest's metadata arrays and
+  calls `SchemaRegistry.registerItem(type, item, 'name', packageId)` — the only
+  seam that runs `applyProtection(item, { packageId })` and stamps `_packageId` /
+  `_provenance`. The key list driving that decomposition (`metadataArrayKeys`,
+  present twice in `packages/objectql/src/engine.ts`: the manifest seam and the
+  nested-plugin seam) carried every other Security-Protocol collection —
+  `permissions`, `sharingRules`, `roles`, `profiles`, `policies` — but not
+  `capabilities`. The other path a stack's security metadata travels,
+  `AppPlugin` → `MetadataManager.registerInMemory`, stamps nothing by design. So
+  `readDeclared(ql, 'capability')` always returned `[]`, and
+  `bootstrapDeclaredCapabilities` — which resolves the owner as
+  `cap._packageId ?? cap.packageId` — could never satisfy the first half.
+
+  The consequence was a contract that lied in the direction that costs the most:
+  `CapabilityDeclarationSchema.packageId` documents itself as the ADR-0086 D3
+  _fallback_ used "when the registry has not stamped `_packageId`", and the field
+  is `.optional()`, but in practice it was **mandatory**. Omitting it produced one
+  boot `warn` and one authorization grant that silently never took effect —
+  permission sets have rows and materialize, capabilities did not.
+
+  **TO.** `capabilities` is registered through the same provenance seam as
+  `permissions`, at both `metadataArrayKeys` sites, and `capabilities` →
+  `capability` joins `PLURAL_TO_SINGULAR` in `@objectstack/spec` so the items land
+  under the singular type name the seeder reads back (the same mapping
+  `AppPlugin`'s security bridge already used). A capability declared by a package
+  — or by a package's nested plugin — now carries `_packageId` /
+  `_provenance: 'package'`, is listable via `registry.listItems('capability')`,
+  and is seeded into `sys_capability` with `managed_by:'package'` and a real
+  `package_id`.
+
+  **What authors should do.** Nothing is required and nothing breaks: an authored
+  `packageId` still parses and still wins where the registry has not stamped
+  (items registered outside a package context). It is now genuinely optional —
+  drop it and the platform supplies the owner. Where both are present the registry
+  stamp takes precedence, as the schema always said; the showcase's
+  `showcase.export_data` keeps its authored `packageId` and names the same id the
+  stack does, so the two agree.
+
+  This does not change what may be created at runtime: `capability` has no entry
+  in `DEFAULT_METADATA_TYPE_REGISTRY`, and the runtime-create gate reads that
+  registry, not the item store — its verdict for the type is the same before and
+  after.
+
+- 58ffcab: fix(objectql): the dangling-reference audit names the objects a finite row
+  budget never reached, instead of dropping them (#5718)
+
+  `auditDanglingReferences` stops the moment `report.scanned >= maxRows`
+  (default 5 000). Every object behind that stop was never opened — and left no
+  trace in the report at all. Its `dangling: []` was indistinguishable from the
+  `dangling: []` of a table that really was read and really was clean, which is
+  the one reading this module is written to prevent: it already carries
+  `truncatedObjects` (the budget ran out INSIDE a table), `unreadableObjects`
+  (the datasource refused) and `aborted` (#4747, the run was called off), and the
+  module header says outright that together they are what stops `0 dangling` from
+  being read as `everything is fine`. Object-level budget exhaustion was the one
+  incompleteness path with no bucket of its own.
+
+  | Key                          | Means                                                                                                              |
+  | :--------------------------- | :----------------------------------------------------------------------------------------------------------------- |
+  | `unscannedObjects: string[]` | objects this run never opened — the overall row budget was gone before their turn, or the run was called off first |
+
+  Notes on the shape:
+
+  - **Names, in scan order** (the `prioritise` tiers), so a caller can feed them
+    straight back as `options.objects` to finish the picture on a second run.
+  - **Optional in the type, always set at runtime** — same contract as `aborted`
+    and #4743's `provenance`: a hand-written report literal (a test double) still
+    compiles, while every report this module produces states the key explicitly,
+    `[]` included. `undefined` therefore never has to be guessed at; it can only
+    mean "a report shape that predates the key", never "complete".
+  - **Two things are deliberately absent from it.** Objects with no reference
+    field at all (nothing referential can break on them, so their silence is
+    proven rather than assumed) and objects the caller excluded via
+    `options.objects` (that is the caller's own narrowing, not the audit missing
+    something).
+  - **It does not raise the summary warning on its own**, exactly like
+    `truncatedObjects` and for the reason #4747 wrote down: a large database
+    exhausts a finite budget on every healthy run, and an alarm that always fires
+    trains its reader past the run that had a real finding. It rides itemised in
+    the warning payload and is always in the returned report.
+
+  #4743 did not cause this — it made it easy to reach. Admitting the provenance
+  family means nearly every object now has an auditable field, so a bounded run
+  spreads the same budget over far more tables and hits the stop sooner. The
+  three-tier scan order that shipped with it decides WHO gets a finite budget;
+  this bucket reports who got none. Only the second one can make a bounded run
+  honest.
+
+- eda599e: fix(platform-objects): 超预算后台 seed 期间不再空库自证 —— 一次启动不再跑两套契约
+
+  #4769 已把 ADR-0104 的空库自证从 `kernel:ready` 挪到 `app:seeded`(本次启动自身数据的结算点),但保留 `kernel:ready` 作为「从不 seed 的内核」的兜底。剩下的窗口是这两个钩子**到达顺序可以颠倒**:`AppPlugin` 的 inline seed 超出软预算(`OS_INLINE_SEED_BUDGET_MS`,默认 8s)后转入后台,于是 `kernel:ready` 先到、兜底自证在 seed 仍在写的时候签发证书并把闸门翻到 strict——同一次 seed 运行的后半段撞上前半段从未见过的契约。showcase 冷启(`OS_INLINE_SEED_BUDGET_MS=1`)实测:自证发生在 +0.470s,seed 结算在 +3.617s,窗口 3.147s。
+
+  现在两个钩子都先问一句「本次启动自己的 seed 落定了吗」,任一处报告仍有未结算的 seed 源就不签发。`app:seeded` 同样受这道检查约束——多 config app 的 bundle 会每个 app 触发一次,第一次并不是本次启动的结算点。
+
+  新增 `seed-settlement` 契约(`@objectstack/spec/contracts`)承载这个信号,而不是让 platform-objects 去嗅 runtime 内部的 `seed-datasets` 服务:那个数组的存在只能说明「seed 源存在」,永远说明不了「已经落定」,而这两件事之间的差正是本 bug 的整个窗口。runtime 在选择分支之前先声明 seed 源,并在写入真正结束的同一刻结算它。
+
+  **multi-tenant 与 `skipSeedData` 的 ADR-0104 姿态(2026-08-06 裁定,#4795)**:这两种部署会注册 seed 数据但在启动时并不写入(前者按 org 在 `sys_organization` insert 时重放,后者是 `os migrate` 的只读规划启动,#3917),`app:seeded` 永不触发。它们的姿态是**启动时不自证,等 `os migrate … --apply` 在真实扫描的证据上落笔**——由同一个判据自然得出,不需要单独分支。这是答案而不是缺口:在启动那一刻断言一次尚未发生的 per-org 重放不含违规值,正是 #4769 的同一个错误、只是引信更长;而停在 warn-first 是可恢复的方向,随时可由 `os migrate value-shapes --apply` / `os migrate files-to-references --apply` 关闭。
+
+  `@objectstack/objectql` 侧只更新了 #4769 撤销机制的注释:「后台 seed 收尾晚于签发」不再是它要兜的场景(已在源头关闭),它对 `os dev` 热重载 seeder、运行期 marketplace 安装以及 lax 开关仍然有效。
+
+- 2b63a00: fix(objectql): a re-registered driver stops crying wolf, and a real name collision starts saying what it cost (#4773)
+
+  Every boot printed one line into `⚠ Boot diagnostics`:
+
+  ```
+  WARN Driver already registered, skipping {"driverName":"com.objectstack.driver.sql"}
+  ```
+
+  It was never an anomaly. The standalone `default` datasource is registered
+  twice, on two legs of one round trip, and traced end to end it is the **same
+  object instance** both times:
+
+  1. `DatasourceConnectionService.attemptConnect()` builds the default driver and
+     registers it (`isDefault: true`), driven by `DefaultDatasourcePlugin.init()`;
+  2. that plugin republishes the instance it just read back out of the engine as
+     the `driver.<name>` kernel service — the surface `os migrate` and serve's
+     storage detection resolve the primary DB through — and
+     `ObjectQLPlugin.start()`'s `driver.*` discovery loop bridges every such
+     service into the engine, handing back the driver it already holds.
+
+  Nothing is decided and nothing is discarded, so `registerDriver` now reports
+  that at `debug`. A no-anomaly line on every single boot does not belong at
+  `warn`; it only teaches operators that `warn` means nothing.
+
+  The reason this is not a blanket downgrade: the same `warn` also covered the
+  case that genuinely matters — **two different driver instances claiming one
+  name**, where "skipping" silently drops one of two configurations (connection
+  string, pool, tenant scoping, capability set) while every query bound to that
+  name keeps working against the winner. The two are now told apart by object
+  identity:
+
+  - **same instance** → `debug`, nothing happened;
+  - **different instance under a held name** → still `warn`, now naming which
+    configuration was KEPT and which was DISCARDED (with both versions) so the
+    operator can tell what is actually in force;
+  - **same instance re-registered with `isDefault` while another driver holds
+    that role** → `warn`, because the caller's intent is otherwise dropped in
+    silence.
+
+  Registration behaviour is unchanged in all three cases — first registration
+  still wins. Only which of them is worth an operator's attention changed.
+
+- afb83d3: `ObjectQL.update` 的三分支派发抽成生产者侧唯一判定 `engine-update-dispatch.ts`
+
+  `delete` 的派发决策自 #4550 起就是一份共享判定(`resolveEngineDeleteDispatch`),任何顶替引擎的测试替身都能 import 它,因此结构上不可能比引擎更宽松。`update` 的同款三分支——标量 `where.id` → 按 id;`options.multi` → `driver.updateMany`;否则抛错——此前只是 `engine.ts` 里的一个内联字面量 throw,既没有导出的常量也没有可复用的函数。后果不是理论上的:#5393 给 flow 的 `update_record` / `delete_record` 补真实契约测试时,delete 侧能把假引擎钉死在生产者契约上,update 侧只能退而断言执行器交出的 options 包,并在文件头写明「不对引擎会不会接受它发表第二份意见」——因为唯一的替代做法是在 fake 里手抄一遍判定,而手抄必然漏掉 `where: { id: { $in: [...] } }` 看着像 id 实为谓词这一半(#4434 正是这样带着全绿的测试发布了一条对每个调用者都回 500 的路由)。同一个执行器的两个写入动词,一个能被绑定到生产者契约、另一个结构上不能,而谓词 update 的破坏性并不低——它覆盖每一行匹配记录的字段。
+
+  本次新增:
+
+  - `packages/objectql/src/engine-update-dispatch.ts`,导出 `resolveEngineUpdateDispatch` / `assertEngineUpdateDispatch` / `scalarUpdateId` / `ENGINE_UPDATE_REJECT_MESSAGE` / `ENGINE_UPDATE_DISPATCH_CASES`,均从 `@objectstack/objectql` 公开导出;
+  - `ObjectQL.update` **自身改用它**——生产者与判定必须是同一份,否则只是第二份副本。
+
+  这是**行为保持的重构**:三分支语义、`$in` 谓词判定、拒绝消息文本一字未改(`Update requires an ID or options.multi=true`,现在是导出常量 `ENGINE_UPDATE_REJECT_MESSAGE`)。判定里有两处刻意照抄而非「改良」了生产者的现状,并在模块头与测试中写明:
+
+  1. `data.id` **不做标量测试**,只要为真就直接作为 id,且优先于 `where` 与 `multi`;
+  2. 分支按**真值**而非 `!== undefined`,所以 `where: { id: 0 }` 不走按 id 路径。
+
+  比生产者更「聪明」的判定就是第二份意见,正是 #4550 消除的东西;这两点该改的时候会在两个文件里一起改,现在那是一次编辑而不是两次。
+
+  新测试 `engine-update-dispatch.test.ts` 不去对照写在旁边的期望表,而是用记录型 driver 驱动**真实引擎**跑完 `ENGINE_UPDATE_DISPATCH_CASES`,逐例断言引擎的实际行为等于判定的裁决——两半唯一同处一室的地方。
+
+- 290d944: fix(objectql): the hook layer logs through the `Logger` contract instead of a local dialect (#5637)
+
+  `packages/spec/src/contracts/logger.ts` declares `error(message, error?: Error,
+meta?)` — the `Error` slot is **second**, the meta bag **third**. Both hook
+  modules declared their own four-method logger shape instead, and that shape
+  spelled `error` as `(msg, meta?)`, so every call site put its diagnostic in the
+  `Error` slot.
+
+  Nothing caught it. The contract's type satisfies the local shape structurally
+  (a function of fewer parameters is assignable, and `any` is compatible both
+  ways), so `tsc` never spoke; and the implementation the platform injects today,
+  `ObjectLogger`, dispatches its second argument **by shape**
+  (`errorOrMeta instanceof Error`), so the meta landed anyway. That tolerance is
+  not something the contract declares. Its two sibling implementations —
+  `ConsoleLogger` / `JsonLogger` in `@objectstack/observability` — follow the
+  contract literally: the meta object lands in the `error` slot, `error.message`
+  and `error.stack` read `undefined`, `meta` **is** `undefined`, and the whole
+  diagnostic evaporates, leaving a bare sentence. The first host to plug a
+  faithful structured logger into `ctx.logger` would have lost the fields of every
+  hook diagnostic, with a symptom ("the log has fewer fields than it used to")
+  that is close to unattributable.
+
+  So the dialect is gone rather than being met halfway (Prime Directive #12 — one
+  contract, no consumer-side dialects):
+
+  - `WrapDeclarativeOptions.logger` and `BindHooksOptions.logger` are now
+    `HookDiagnosticsLogger` = `Pick<Logger, 'debug' | 'info' | 'warn' | 'error'>`,
+    taken from `@objectstack/spec/contracts` — the four levels this layer calls,
+    and nothing more.
+  - All four `error(...)` call sites pass the meta in the contract's third
+    parameter (`error(msg, undefined, { … })`). The values in hand at each site
+    are a `CelFault` (`{ kind, message }`) or a `catch` binding of type `unknown`,
+    none of them statically an `Error`, so the `Error` slot stays empty and each
+    message is carried in meta exactly as before.
+
+  `debug`/`info`/`warn` already matched the contract and are unchanged.
+
+  No behaviour change for hosts on `ObjectLogger` (the default, and what
+  `ctx.logger` / `engine.logger` supply): it accepts all three shapes since #5575,
+  so an empty `Error` slot renders the same record it rendered before. Callers
+  passing a full `Logger` are unaffected — a `Logger` satisfies the narrowed type
+  unchanged. A caller that hand-rolled a four-method object still satisfies it too,
+  as long as its `error` does not _require_ a meta object in the second position;
+  if yours does, move that parameter to third — the contract's order is now the
+  one the hook layer calls with.
+
+- 7f1a635: fix(lint,spec,objectql): 编写期表达式与 `highlightFields` 校验识别注册表注入的系统列 (#5378)
+
+  平台在每个业务对象上注入 `owner_id` / `created_at` / `organization_id` 等系统列,
+  文档也把 `ownership: 'user'` 写作 "injects reassignable owner_id"。但编写期的两处
+  校验只读**作者声明的** `fields`,于是注入列一律当作不存在:
+
+  - `validate-expressions.ts` 的 `buildFieldIndex` 让 `has(record.owner_id)` 直接
+    报错 `unknown field owner_id`;
+  - `highlightFields` 存在性检查对 `['owner_id']` 发出 "is not a field on this
+    object — it is silently skipped by every consumer"。
+
+  也就是平台自己的 linter 否认平台自己的契约。结果是应用被迫**重声明系统列**才能通过
+  编写期校验:hotcrm#548 为此在全部 12 个业务对象上显式声明了 `owner_id`(6 个对象曾
+  报 `highlightFields` 警告,`contact_welcome` 触发器的 `has(record.owner_id)` 被硬
+  拒)。这正是本项目视为缺陷的形状:能力已声明(列确实注入且有文档),但执行层不认。
+
+  **权威来源只有一份。** 新增纯派生 `resolveInjectedSystemColumns()`
+  (`@objectstack/spec/data`)回答"这个对象带哪些系统列",并由 registry 的
+  `applySystemFields()` **消费**它——沿用 #3786 为审计字段族确立的分工:spec 声明
+  **有哪些**列,registry 拥有**每列长什么样**。lint 通过同一派生取答案,因此编写期
+  判断与运行时注入不可能不一致(`@objectstack/lint` 的包契约是"只依赖 spec,绝不依赖
+  运行时",此前它根本无法读到权威)。两个消费面共用同一判定,不各写一份。
+
+  **并入是按对象有条件的**,不是无条件放行整张系统列名单:`ownership: 'org' | 'none'`
+  的对象没有 `owner_id`,那里的 `record.owner_id` 仍然是真错误并继续报;
+  `tenancy.enabled: false` 无 `organization_id`;`systemFields: { audit: false }` 无
+  审计四列;`systemFields: false` / `managedBy: 'better-auth'` 什么都不注入(只剩驱动
+  提供的主键 `id`)。真正拼错的字段照旧被拒,并且注入列现在也进入 "did you mean?" 候选
+  (`record.ownerid` → 提示 `owner_id`)。
+
+  被解析的注入列在诊断与补全语义上与授权字段等同;类型健全性与 null-guard 两个索引
+  **刻意**仍只读声明字段,原因写在各自注释里:列的 `type` 与可空性属于 registry 的列
+  定义,在 lint 侧另立一份就是本次要消灭的第二份副本,而 null-guard 喂的是会中断构建的
+  判定,擅自并入会让今天能构建的 stack 变红。
+
+  注入行为本身零改动:`applySystemFields` 的输出在全条件矩阵上逐列不变(新增 parity
+  pin 用实跑注入代码比对)。已显式重声明系统列的应用不受影响——重声明仍然合法,
+  examples 三个 app 的 `os validate` 输出改动前后完全一致。
+
+- 1eadac0: lifecycle: the Archiver's batch loop now honours the teardown abort bit (#4747)
+
+  `LifecycleService.stop()` raises an abort bit that the sweep checks at each leg
+  boundary — between objects, and (since #5753) between reap pages. The Archiver's
+  own batch loop did not check it, so teardown landing mid-archive still ran the
+  remaining batches out: up to 20 × 500 rows of `find` + per-row `upsert` +
+  `bulkDelete` issued across two datasources the host is already closing.
+
+  It now breaks at the batch boundary like the reap loop does. The "hot-delete only
+  what the cold store took" safety rule is unaffected: the batch in flight finishes
+  its `upsert` → `bulkDelete` pair, and batches not yet begun are left for the next
+  sweep to re-read.
+
+  Not reachable in any of today's deployments — the Archiver only engages once an
+  object declares `archive` with a provisioned cold datasource, and no platform
+  object does. This is prevention for the first deployment that declares one.
+
+- 9b26699: fix(objectql): bound every lifecycle reap, not just the guarded ones
+
+  `LifecycleService.reap()` issued a single unlimited `delete(..., { multi: true })`
+  per sweep for any object without a registered reap guard — no limit, no paging.
+  Batching existed only on the two side paths (`guardedReap` and the Archiver,
+  both 500 × 20 per sweep), whose comment gives the reason plainly: "bound one
+  sweep's work, drain the backlog across sweeps". That reason never depended on a
+  guard being registered.
+
+  Steady state was fine — an hourly sweep deletes a small increment. The cost
+  landed exactly once per table, on the first sweep after `retention` is declared
+  on a table that already holds history: one DELETE scanning every historical row,
+  which on SQLite holds the whole database's write lock for its duration and on
+  Postgres arrives later as autovacuum debt.
+
+  Unguarded reaps now run the same batched machinery the guarded ones do — an
+  object with no guard is simply the empty guard intersection, which confirms
+  every candidate row — so there is one reap path rather than two parallel ones.
+  Candidates are read a page at a time and deleted by id, at most 500 × 20 rows
+  per object per sweep, with the remainder draining on later sweeps. Cutoff and
+  `retention.onlyWhen` predicates are unchanged; they now select the candidate
+  read. The sweep report's `deleted` count reflects rows actually deleted this
+  sweep.
+
+  Two consequences worth knowing:
+
+  - A reap fires one `afterDelete` hook per reaped row instead of one per object
+    per sweep. Every lifecycle-declaring platform object is in the audit writer's
+    `SKIP_OBJECTS`, and `sys_file` already reaped per id via its guards, so no
+    object in the platform changes its audit output.
+  - An engine that does not implement `find` cannot page and keeps the previous
+    single bulk DELETE, so retention enforcement never silently stops on it. Every
+    real engine implements `find`.
+
+- 1c625ca: metadata: `getDiagnosed` — a metadata read that FAILED stops arriving as "nobody declared this"
+
+  `MetadataManager.loadDiagnosed` computes the ADR-0110 D3 verdict (a MISS and an OUTAGE
+  are different facts with opposite security meanings) and `get()` discarded it two hops
+  later: `load()` kept only `.data`, `get()` turned that `null` into `undefined`. Every
+  consumer of `get()` therefore received one `undefined` for two opposite facts and could
+  not have told them apart even if it had wanted to.
+
+  **New read.** `MetadataManager.getDiagnosed(type, name)` returns
+  `{ data, degraded, errors }` — the registry-first counterpart of `loadDiagnosed`, declared
+  as an optional member of `IMetadataService`. A registry hit is never degraded (it
+  consulted no loader); a clean miss is never degraded (every loader answered).
+
+  **`get()` is unchanged — zero breaking.** Same signature, same answer, same behaviour for
+  every existing caller, including the microtask-level ordering `register()`'s watchers
+  depend on. Only callers that ASK for the verdict pay for it. Making `get()` throw on
+  `degraded` was deliberately not done: the boot path degrades on purpose.
+
+  **Consumers switched**, each with a disposition argued for its own context rather than one
+  blanket rule:
+
+  - `getMetaItem` / `getMetaItemCached` — a degraded MetadataService read with nothing in
+    the registry now raises `503 SERVICE_UNAVAILABLE` instead of falling through to
+    `404 RESOURCE_NOT_FOUND`. This is the half that made the existing `#5532` comment ("
+    reaching here now means a real miss") untrue.
+  - `getMetaItemLayered` — the `code` layer joins the rule its `overlay` layer already
+    followed. `code: null` is a positive claim, and `lockSource = code ?? overlay ?? {}`
+    derives from it, so an outage could render an item the packager locked
+    (`_lock: 'full'`) as `editable: true, deletable: true`.
+  - `ObjectQLPlugin`'s `object` metadata-event refresh — logs `warn` naming the consequence
+    (the registry keeps the previous definition; nothing retries) and the fix, instead of
+    `debug` "metadata service has no fresh body". `warn` and not `error` because the write
+    already landed; only a re-read failed.
+
+  Hosts whose `metadata` slot is a shim that predates `getDiagnosed` are read as
+  "not degraded" — exactly what they could express before — so their behaviour is unchanged.
+
+- 1cae606: fix(objectql): resolve the `NOW()` defaultValue token in the engine, so it works on every datasource (#4597)
+
+  `Field.datetime({ defaultValue: 'NOW()' })` only ever worked on SQL. The engine's
+  `applyFieldDefaults` special-cased exactly two `defaultValue` shapes — the
+  Expression envelope and the `current_user` token — and passed everything else
+  through verbatim, so the four characters `NOW()` were written into the record as
+  a **literal string**. The SQL driver hid that: `SqlDriver.formatInput` carries an
+  insert-time safety net that swaps any `NOW()` string for a real ISO timestamp
+  before it hits the wire. Memory and MongoDB have no such net.
+
+  This is the mirror image of #4560. There, `current_user` was known to the engine
+  and not to the DDL, so the DDL stored the token text. Here, `NOW()` was known to
+  the SQL driver and not to the engine — same crack, opposite side. It surfaced two
+  ways:
+
+  - On a **validated** field the insert was **rejected outright**, by the engine's
+    own write validator, against a value the engine itself had just filled in:
+    `ValidationError: … must be a valid datetime (ISO-8601)`. Every insert omitting
+    such a field failed, with an error naming a field the caller never sent.
+  - On a `readonly` / `system` field — which `validateRecord` skips, i.e. the ~100
+    `created_at` / `updated_at` declarations across the platform objects — nothing
+    was rejected at all and the string `NOW()` was **stored**.
+
+  `applyFieldDefaults` now resolves the token itself, from the same per-insert
+  `now` snapshot it already passes to Expression defaults, so every field defaulted
+  in one insert (and every row of one batch) carries the identical instant. The
+  spelling it matches is the spec's (`isNowDefaultToken` from
+  `@objectstack/spec/data`, case-insensitive and whitespace tolerant), the same
+  predicate a driver's DDL consults — the engine does not re-derive its own.
+
+  The token resolves into the shape the field's **declared type** stores, which is
+  what `SqlDriver.nowColumnDefault` already emits per type (ADR-0053), so no
+  datasource disagrees about the stored form:
+
+  | field type                                          | stored value                                                |
+  | --------------------------------------------------- | ----------------------------------------------------------- |
+  | `date`                                              | `YYYY-MM-DD` (UTC calendar day)                             |
+  | `time`                                              | `HH:MM:SS[.fff]` (UTC wall clock; a zero `.000` is trimmed) |
+  | `datetime`, and any non-temporal field that opts in | `YYYY-MM-DDTHH:MM:SS.sssZ`                                  |
+
+  No authoring change: `defaultValue: 'NOW()'` is the same declaration it always
+  was, and a caller-supplied value is still never overwritten. What changes is that
+  it now means the same thing on memory and MongoDB as it always did on SQL.
+  Records written on a non-SQL datasource before this fix may hold the literal
+  string `NOW()` in those columns; they are not rewritten.
+
+  Both driver-side mechanisms stay, unchanged, as defence in depth: `formatInput`'s
+  safety net (now unreachable from the engine's insert path) and the native column
+  DEFAULT, which still serves writes that bypass the engine entirely — the same
+  division of labour `current_user` has.
+
+- b9cc17d: chore(objectql): retire `applyFormulaPlan`'s zero-caller `nowSnapshot` parameter and narrow its docstring to what actually holds (#5699)
+
+  `applyFormulaPlan` declared a fourth optional parameter `nowSnapshot?: Date`
+  whose only effect was `nowSnapshot ?? new Date()`. Not one of its three call
+  sites ever passed it — `find`, `findOne`, and the write-response hydration
+  `hydrateWriteFormulas` added by #5504 — so the parameter went down the
+  `new Date()` branch from birth. Dormant code, removed rather than archived: a
+  parameter that looks live is worse than no parameter, because everyone
+  reasoning from it concludes the caller can pin the instant, and one caller
+  plainly should have.
+
+  No behaviour change (the removed branch was unreachable), no public API change
+  (`applyFormulaPlan` is module-private and never exported).
+
+  The docstring claimed the eval context "mirrors `applyFieldDefaults`". Half of
+  that was true — the same keys, so `formula` and `defaultValue` expressions share
+  one vocabulary — and half was not: the two pin their own `now`.
+  `applyFieldDefaults` is handed the insert's pre-write snapshot, while
+  `applyFormulaPlan` reads the clock once per call, because a formula is evaluated
+  when a record is materialized. So inside one `insert` a `NOW()` default and a
+  `now()` formula observe two instants a driver round-trip apart (sub-millisecond
+  in practice; across a second/day boundary they can land on different calendar
+  days). The docstring now says so, and names #5699 as where making them share one
+  instant would have to be argued — it would hand the write path a determinism
+  guarantee the read path cannot have, which is a semantic decision, not a cleanup.
+
+  Adds the pins that the retired parameter's _appearance_ was standing in for
+  (`engine-write-formula-hydration.test.ts`): one snapshot per call shared by every
+  row × every formula field, asserted by object identity on the eval context so a
+  per-evaluation `new Date()` fails even when the milliseconds agree, on the write
+  path and the read path alike; plus a tripwire that the default's instant and the
+  formula's instant stay independently sourced.
+
+- 0d24078: fix(objectql): `wantOwner` 由排除式改为正面清单,并注入 `owning_business_unit_id`(ADR-0117 D1,#5677)
+
+  `applySystemFields` 判定是否注入 `owner_id` 的 `wantOwner` 原本是**排除式**的
+  (`ownership !== 'org' && ownership !== 'none'`):只有两个值被排除,任何第四个
+  `ownership` 值都会掉进默认分支、照常被盖上 `owner_id`。这与 ADR-0117 D1 的表格
+  **恰好相反**——新增的 `business_unit` 档的全部含义就是「归属于组织单元而非个人」
+  (`owner_id` ❌、`owning_business_unit_id` ✅)。#4611 的一次性探针已实测确认过这个
+  反向结果。
+
+  **翻面。** 判定改为正面清单 `ownership === undefined || ownership === 'user'`
+  (`managedBy` 平台表与 `sys_` 命名空间的跳过规则不变)。对今天存在的三个值
+  **行为完全不变**:`undefined`/`user` 照常注入,`org`/`none` 照常排除;唯一的变化是
+  新档位不再靠「落进默认分支」继承 owner 语义。这是先决单点:先翻面,枚举扩展
+  (#5678)才是安全的。
+
+  **注入 `owning_business_unit_id`。** 记录级组织单元归属(lookup → `sys_business_unit`),
+  按 D1 表格覆盖 `undefined`/`user`/`business_unit` 三档,`org`/`none` 不注入。
+
+  | `ownership`          | `owner_id` | `owning_business_unit_id` |
+  | -------------------- | ---------- | ------------------------- |
+  | `undefined` / `user` | ✅         | ✅                        |
+  | `business_unit`      | ❌         | ✅                        |
+  | `org` / `none`       | ❌         | ❌                        |
+
+  **用户可见的行为变化**:声明 `ownership: 'business_unit'` 的对象此前会被误注入
+  `owner_id`,现在改为注入 `owning_business_unit_id`。(该值今天仍被 `ObjectSchema`
+  的枚举拒收 —— 枚举扩展在 #5678,严格后置于本单;所以本次发布中这条路径只有
+  引擎侧就绪,尚无法从元数据声明触达。)
+
+  列的形态比照 `organization_id`(服务端盖章的作用域锚点)而非 `owner_id`(用户可指派
+  的业务字段):`readonly: true` + `hidden: true` + `required: false`,不建索引。三者
+  都**不预设** ADR-0117 D2 尚未裁定的盖章策略(`pinned`/`follow_owner`/`transferable`)
+  ——它们不授予任何能力,因此 D2 的每种结论都仍然可达;盖章中间件(D2/D4)与回填
+  (D8)落地前,该列被提供但处于惰性状态(恒为 NULL)。
+
+  `packages/spec` 未改动:`SystemFieldName.OWNING_BUSINESS_UNIT_ID` 的 JSDoc 与
+  `object.zod.ts` 的描述同步在 #5767。该名早已在公开表单 server-managed 拒收名单上
+  (#4611 提前登记),因此新列从第一天起就不可由匿名面客户端提供。
+
+- 2ddba89: fix(tenancy): eight sites answered "is this deployment multi-org?" with the demoted `OS_MULTI_ORG_ENABLED` (#5262)
+
+  ADR-0105 D1 made `OS_TENANCY_POSTURE` the authoritative knob and demoted
+  `OS_MULTI_ORG_ENABLED` to a back-compat _input_ of `resolveTenancyPosture()`.
+  A deployment configured the documented way — `OS_TENANCY_POSTURE=isolated` (or
+  `group`), legacy boolean unset — therefore reads `false` from
+  `resolveMultiOrgEnabled()` while running a fully mounted organization wall.
+  #5233 corrected two sites in `plugin-auth`; a census found eight more, all
+  written before that function's doc comment was corrected. Third recurrence of
+  the shape (cloud#1020, #5233).
+
+  Each site was judged separately for **which** posture answers its question —
+  what the operator REQUESTED, or what the `tenancy` service reports is actually
+  IN FORCE — rather than converted mechanically:
+
+  - `objectql` `SchemaRegistry` — the env-derived multi-tenant default. Reads the
+    REQUESTED posture (it is constructed below the kernel, with no service
+    registry to ask). The `organization_id` column was always provisioned; what
+    diverged is its INDEX, so a posture-only deployment ran the Layer 0 wall's
+    hottest predicate unindexed while SecurityPlugin compiled that same wall.
+  - `plugin-dev` — whether to load the enterprise `@objectstack/organizations`.
+    REQUESTED posture, mirroring `serve.ts`: this branch is what mounts the wall,
+    so asking whether the wall is up would be circular. A posture-only dev stack
+    previously never loaded the package at all and served traffic unwalled. Its
+    diagnostic now names the posture that was requested instead of asserting
+    `OS_MULTI_ORG_ENABLED=true` at an operator who never set it.
+  - `runtime` `AppPlugin` (inline seed + hot-reload seeder) — EFFECTIVE posture,
+    via the `tenancy` service. These ask "will the per-org replay run instead of
+    me?", and on an ADR-0093 D5 degraded boot that replay does not exist, so
+    keying on the request would defer to a replay that can never happen. Walled
+    deployments previously inline-seeded exactly the NULL-organization rows the
+    code's own comment exists to avoid.
+  - `cloud-connection` marketplace local install (install-time seed + rehydrate
+    heal) — EFFECTIVE posture, same reasoning. The install path is a write path:
+    a walled deployment wrote every sample row with no `organization_id`, landing
+    the app's data outside the wall its own reads apply.
+  - `driver-sql` `isMultiTenantMode()` — REQUESTED posture (a driver has no
+    kernel to ask, and a suppressed warning is the costlier error for a
+    diagnostic). It also no longer memoises into `_multiTenantMode`: that froze a
+    process-level fact into a per-instance verdict on whichever write landed
+    first. The gate now resolves live, which is affordable because
+    `auditMissingTenant` consults it only after the `tenantId` early-out.
+  - `cli` `os verify` — REQUESTED posture. This one produced a green verification
+    run over an unverified property: a posture-only deployment silently skipped
+    every multi-tenant proof and exited 0.
+
+  **No configuration change is needed anywhere.** Deployments setting only
+  `OS_MULTI_ORG_ENABLED=true` keep working unchanged — `resolveTenancyPosture()`
+  falls back to it — and the `OS_TENANCY_POSTURE=isolated` + `OS_MULTI_ORG_ENABLED=true`
+  belt-and-braces configuration stays valid. Deployments that set only
+  `OS_TENANCY_POSTURE` can now drop the redundant boolean. Single-org behaviour is
+  unchanged at every site; only the knob each one reads is corrected.
+
+- 37a8f2b: fix(objectql): the static-`readonly` write strip now logs its consequence and its remedy
+
+  Writing a `readonly: true` column from server-side code — a cron job or background
+  task reaching the engine through `ctx.getService('data')` — dropped the value and
+  reported success. The only trace was:
+
+  ```
+  WARN Field 'work_duration' is read-only — ignoring incoming change (#2948)
+  ```
+
+  which says what the engine did, not what it cost the caller or how to fix it. The
+  downstream symptom is a field that persists fine through every REST path and never
+  persists from cron (os-project-titanwind-ehr#750), which reads as "cron is broken"
+  rather than "the value was stripped". The strip now names the object, states that
+  the update was **committed without the field**, and carries both remedies: trusted
+  server code declares itself with `{ context: { isSystem: true } }`, and any caller
+  can detect drops programmatically with `options.onFieldsDropped` (the machine-readable
+  strip signal that has existed since #3407 — one event per strip pass, with `fields`
+  and `reason`).
+
+  The level stays `warn`, deliberately: this seam cannot distinguish a hostile REST
+  body forging `created_by` from trusted server code, because `ExecutionContext`
+  carries no origin marker and `isSystem` — the only trust bit — is precisely the
+  exemption. `error` would make the error log client-triggerable; `debug` would restore
+  the silent drop.
+
+  Behaviour is unchanged: what is stripped, what survives, and what `onFieldsDropped`
+  reports are all identical. Documented in the [security protocol
+  page](/docs/protocol/objectql/security) — strip condition, the caller-supplied-keys
+  scope, why a `beforeUpdate` hook's backfill is exempt (the key snapshot is taken at
+  engine entry, before hooks run), and the `isSystem` convention for plugin writes —
+  and pinned in `engine-readonly-strip-signal.test.ts`.
+
+- 2680cd3: fix(objectql): `seedAutonumber` 把非「表未建」的读故障上抛,不再从 0 重发自增号 (#5979)
+
+  引擎在 driver 不自带自增序列时,走 fallback 路径:先从库里读 `MAX(existing)`
+  给内存计数器播种,再自增发号。这次播种读此前挂在一个裸 `} catch { return 0; }`
+  后面 —— **所有**失败(连接断开、超时、权限拒绝、查询错误)都被答成跟「表里真的
+  一行都没有」完全相同的 `0`。
+
+  这两件事是相反的事实(ADR-0110 D3),在这里混淆是 #4728 / #4825 / #5108 同族里
+  代价最高的一支:对一张已经有 N 行的表,一次抖动的读就让序列从 1 重新开始,发出
+  与既有行**相撞**的自增号。插入是**成功**的,一行日志都没有,而撞号落在业务标识符
+  上 —— 一个写错了的值,重试修不好,重启也修不好。危险本身早就写在那个读上方的
+  注释里(#4371:"the catch below would have swallowed the guard's rejection into
+  'seed from 0', i.e. duplicate autonumbers");当时读被修了,catch 没有。
+
+  现在按错误**类型**判别,问的是共享谓词 `isMissingTableError`
+  (`@objectstack/metadata/errors`,#4825),而不是手抄一份 `code === '42P01'`:
+
+  - **表尚未 provision** → 仍旧从 0 起号。库里确实没有行,1 号不会撞到任何东西,
+    这是唯一良性的失败原因,行为与此前完全一致。
+  - **其余任何读故障** → 原样上抛,**不发号、不写入**。行没被看见不等于行不存在,
+    所以引擎拒绝用一份自己从没读到的数据去推算号段。
+
+  **行为变化(升级须知)**:自增字段所在对象的写入,在存储读故障期间会**失败**,
+  而不再像以前那样"成功"并写入一个可能撞号的编号。这是有意的 —— 一次响亮的失败
+  可以重试,一个静默写错的业务编号不能。故障恢复后下一次插入会重新播种并从真实的
+  `MAX(existing)` 继续(失败的播种不会污染内存计数器)。
+
+- db2ea82: fix(objectql): a single-record `delete()` binds `hookContext.previous` — the pre-image the contract has always promised (#5272)
+
+  `HookContext.previous` is documented in the spec as _"the state of the record
+  BEFORE the operation (**for update/delete**)"_, and `update()` has bound it all
+  along. `delete()` never did. `previous` was `undefined` in **both**
+  `beforeDelete` and `afterDelete`, for every single-record delete, on every
+  object.
+
+  That is not a cosmetic gap. Since #4775 a condition that cannot be evaluated
+  **fails the operation**, so a legal, contract-shaped delete-side hook:
+
+  ```ts
+  { events: ['afterDelete'], condition: "previous.status == 'done'" }
+  ```
+
+  rejected _every_ single-record delete of that object — and reported it through
+  the generic branch (`Unknown variable: previous`), which reads like the author
+  misspelled a key. The key was fine; the engine never bound it. Same shape as
+  #5037: a platform gap surfacing as the author's mistake.
+
+  **Why now.** #5038 made a predicate bulk delete dispatch `afterDelete` once per
+  matched row, each carrying that row's own pre-image. The single-record path
+  still bound nothing, so it became strictly _worse_ than the bulk path — the
+  exact inversion the #4800/#4862 ruling ("an author writes the hook once; single
+  and bulk mean the same thing") exists to prevent.
+
+  **What changed.** `delete()` now takes the doomed row's pre-image once, before
+  `beforeDelete` fires, and binds it to `hookContext.previous` for both phases —
+  so hook `condition`s, record-change flow triggers and delete-audit handlers all
+  see the deleted row. The read is demand-driven, exactly like `update()`'s: it
+  happens only when the object has a delete-side hook (either phase) or a roll-up
+  summary aggregating it. An object with neither pays nothing, and an object with
+  both phases pays **one** read, not two — the roll-up path's own separate
+  pre-image fetch has been folded into this one, and is now the same raw driver
+  read `update()` already feeds the summary recompute.
+
+  Nothing is fabricated: if the row is not there, `previous` stays **unbound**
+  rather than becoming `{}`/`null`, so a condition reading it still faults loudly
+  instead of answering for a record nobody read (#4649/#4775). The batch dispatch
+  of a predicate delete still carries no `previous` — it stands for N rows — and
+  its per-row `afterDelete` contexts are unchanged.
+
+  Upgrade impact: a delete-side hook whose `condition` reads `previous` starts
+  evaluating instead of rejecting the write, and delete-side handlers start
+  receiving `ctx.previous`. If you worked around the gap by testing
+  `ctx.previous == null` to detect "this is a delete", that test now answers
+  differently — read `ctx.event` instead.
+
+- 51a587d: 两个写动词的派发判定下沉到 `@objectstack/metadata-core` —— 公共 API 零变化,一次关闭 26 条 engine-double 基线条目
+
+  `ObjectQL.delete` / `ObjectQL.update` 的三分支派发判定(`engine-delete-dispatch.ts` #4550、
+  `engine-update-dispatch.ts` #5480)从 `packages/objectql/src/` **原样搬到**
+  `packages/metadata-core/src/`。这是一次搬移,不是重构:两个模块本来就零 import、纯自包含,
+  判定逻辑一个字未改。
+
+  **为什么搬。** `@objectstack/objectql` 的 `dependencies` 含 `@objectstack/metadata-protocol`,
+  所以那个包里 13 个假引擎结构性地无法 import 这两个谓词 —— 反向 devDependency 即成环,
+  turbo 2.10.7 直接拒绝任务图。判据来自门禁台账里
+  `packages/spec/src/contracts/data-engine.test.ts` 那条 EXEMPT:反向 import 不可行时,唯一
+  出路是下沉到**两边都已依赖**的包。`@objectstack/metadata-core` 正是这个包
+  (`objectql -> metadata-core` 与 `metadata-protocol -> metadata-core` 都是既有边),而它自己
+  的 `dependencies` 只有 `{ @objectstack/spec, zod }`,不含 objectql,故不引入新环。
+
+  **公共 API 与既有调用点零变化。** `packages/objectql/src/engine-delete-dispatch.ts` /
+  `engine-update-dispatch.ts` 保留在原路径,改为 re-export shim,因此
+  `@objectstack/objectql` 仍然导出
+  `resolveEngineDeleteDispatch` / `assertEngineDeleteDispatch` / `scalarDeleteId` /
+  `ENGINE_DELETE_REJECT_MESSAGE` / `ENGINE_DELETE_DISPATCH_CASES` 及 update 侧的五个同名对应物
+  (与全部类型),`engine.ts` 与 37 个既有 pinned 调用点一行未动。同一批符号现在也从
+  `@objectstack/metadata-core` 导出。
+
+  搭配的门禁改动:`scripts/check-engine-double-contract.mjs` 的两个 slice 现在同时接受
+  `@objectstack/metadata-core` 与 `@objectstack/objectql` 两种拼写(它们指向同一个函数),
+  失败提示也改为在「objectql 依赖该包」时优先建议 metadata-core。
+
+- d56bcdb: fix(objectql): 新建父行时把 count/sum 型 `Field.summary` 汇总字段初始化为 0
+
+  `recomputeSummaries()` 只会重算「本次子记录写入所指向的父行」,所以一个**从未有过子记录**的父行永远不会被访问到,汇总列停在 insert 时的 `null`;而把最后一条子记录**删掉**的父行反而会被访问到(经由 `previous`)并落到 `0`。同一个「零个子记录」的逻辑状态因此读出两个不同的值。
+
+  后果不是显示难看,而是**筛选静默漏行**:`["task_count","=",0]` / `["task_count","<",1]`(库内比对)会把「从来没建过任务的项目」整行丢掉,没有任何报错;排序、GROUP BY、以及以该字段为输入的公式字段(null 传播)同样受影响。
+
+  本次在**生产端**修:父行 insert 时,按父对象取一份 summary descriptor,把该行自己拥有的 `count` / `sum` 汇总字段落成空集合的值 `0` —— 与 `recomputeSummaries` 的空集兜底共用同一份函数清单(现已提取为单一来源),所以「从未有过子记录」与「删光子记录」必然读到同一个值。`min` / `max` / `avg` 在空集上没有定义,仍然保持 `null`,口径不变。
+
+  边界:
+
+  - 作者显式提供的值不会被覆盖(与 `applyFieldDefaults` 同口径:insert 时 `undefined` 与显式 `null` 都算「未提供」);`beforeInsert` 钩子仍有最终决定权。
+  - 关系无法解析的汇总字段不落初值 ——「落了初值」与「会被重算维护」是同一个集合,不会出现一个没人维护的 `0`。
+  - **存量数据不受本 PR 影响**:这是 create-time 初始化,已经存成 `null` 的老父行仍然是 `null`,直到某次子记录写入把它重算。存量回填是独立取舍,另行处理。
+
+- 488b66c: fix(objectql): say out loud when `transaction()` is not giving you a transaction (#4619)
+
+  `ObjectQL.transaction()` carries two caveats that are part of its **declared**
+  meaning (ADR-0119 D1, `packages/spec/src/contracts/objectql-engine.ts`), not
+  hidden behaviour:
+
+  1. when the default driver has no `beginTransaction`, the callback runs with no
+     transaction and no rollback;
+  2. the transaction covers the **default** datasource only, so an object routed
+     elsewhere by `setDatasourceMapping` is written outside it.
+
+  Declaring them is not the same as being able to observe them, and both were
+  completely mute. A caller asking for atomicity and not getting it had no way to
+  find out; a multi-datasource "atomic" unit of work that partially committed
+  reported nothing at all — one store reverted, the other kept its rows, and the
+  caller saw only that the whole thing failed. That is the same shape as
+  `batchData`'s `atomic` flag being a lie for as long as it was (ADR-0119 D4).
+
+  **Nothing about what the engine does has changed.** Both caveats still hold
+  exactly as declared; this release only makes them discoverable.
+
+  - **`warn`, once per driver per engine instance**, when `transaction()` (or
+    `ctx.api.transaction()` in a sandboxed hook/action body) degrades because the
+    driver has no `beginTransaction`. The line names the driver, the consequence
+    — writes commit as they execute, so a later throw leaves the earlier ones
+    persisted while the call rejects as if nothing had landed — and the fix.
+    `warn` rather than `error` on purpose: at that moment nothing has been lost,
+    a capability is simply absent, which is the functional-degradation branch
+    AGENTS.md keeps at `warn`. Once per driver because the drivers that reach
+    this path (test doubles, foreign engines) reach it on _every_ call.
+
+  - **`error`, once per transaction per datasource**, when an `insert`/`update`/
+    `delete` inside an open `transaction()` is routed to a driver that
+    transaction does not cover. The line names the object, the datasource it went
+    to, the datasource the transaction was opened on, and says the write commits
+    on its own and will survive the rollback. `error` per AGENTS.md's judgment
+    question: afterwards the system looks entirely normal from the outside while
+    a write it claimed was part of an atomic unit has landed by itself — the
+    durability class, not the functional one.
+
+  Both diagnostics are reported by the engine, so the direct
+  (`engine.transaction`) and sandboxed (`ScopedContext.transaction`) surfaces
+  share one budget and one wording rather than drifting apart.
+
+  Tightening either caveat — an `opts.require` that throws instead of degrading,
+  refusing a cross-driver write, or surfacing an owned-vs-joined signal to the
+  callback — would change the contract's declared semantics and is deliberately
+  **not** done here; that half of #4619 is tracked separately against
+  `packages/spec`.
+
+- 946a131: fix(metadata-core,objectql): `ObjectQL.update` 的 `data.id` 同过标量测试,不再把载荷里的算子对象当主键 (#5748)
+
+  `ObjectQL.update(object, data, options)` 用两处取主键,而这两处此前用的是**两套规则**:
+
+  - `options.where.id` 走**标量测试** —— `{ id: { $in: [...] } }` / `{ id: [...] }` /
+    `{ id: null }` 是多行谓词,不算 id(#4434 / #4550);
+  - `data.id` **不做任何测试**,只要为真就原样当主键,并且先于 `where`、也先于
+    `options.multi`。
+
+  于是同一个算子对象,写在 `where.id` 里被正确识别为谓词,写在 `data.id` 里却被
+  当成主键绑进 `driver.update(object, id, …)` 的主键位置,**显式声明的
+  `multi: true` 被无声忽略**。后果不是数据被覆盖,而是静默失灵或难读的驱动错误:
+  SQLite 侧报参数绑定错误,别的驱动可能只匹配零行 —— 两种都不会告诉调用方
+  「你的 `multi` 被忽略了」。这是 declared ≠ enforced 的一种,#5393 刚给 flow 的
+  `update_record` 补上的 `multi` 批量意图键正是被这条更早的规则盖掉的。
+
+  现在 `data.id` 与 `where.id` **共用同一个标量测试**(判定在
+  `packages/metadata-core/src/engine-update-dispatch.ts` 定义一次,`engine.ts` 与
+  全部 fake engine 经 `resolveEngineUpdateDispatch` /
+  `assertEngineUpdateDispatch` 复用同一份)。非标量 `data.id` 不算 id,因此不再
+  盖住任何东西:判定按 `where.id` → `multi` → `reject` 的原有阶梯继续往下走。
+
+  **行为矩阵(FROM → TO)。标量 `data.id` 的按 id 写法完全不受影响。**
+
+  | 调用                                                                | FROM                       | TO                                                                |
+  | :------------------------------------------------------------------ | :------------------------- | :---------------------------------------------------------------- |
+  | `update(o, { id: 'rec_1', …f })`                                    | by-id `'rec_1'`            | **不变**                                                          |
+  | `update(o, { id: 'rec_1', …f }, { multi: true })`                   | by-id `'rec_1'`            | **不变**(标量 `data.id` 仍先于 `multi`)                           |
+  | `update(o, { id: 'rec_1', …f }, { where: { id: 'rec_2' } })`        | by-id `'rec_1'`            | **不变**(标量 `data.id` 仍先于 `where`)                           |
+  | `update(o, { id: 0, …f }, { multi: true })`                         | multi                      | **不变**(真值判定,`0` 不标识行)                                   |
+  | `update(o, { id: { $in: [...] }, …f }, { multi: true })`            | by-id,算子对象被绑进主键位 | **multi** —— 声明的批量意图被执行                                 |
+  | `update(o, { id: ['a','b'], …f }, { multi: true })`                 | by-id,数组被绑进主键位     | **multi**                                                         |
+  | `update(o, { id: { $in: [...] }, …f })`(**无** `multi`)             | by-id,算子对象被绑进主键位 | **reject**,消息不变:`Update requires an ID or options.multi=true` |
+  | `update(o, { id: { $in: [...] }, …f }, { multi: false })`           | 同上                       | **reject**                                                        |
+  | `update(o, { id: { $in: [...] }, …f }, { where: { id: 'rec_1' } })` | by-id,绑的是**算子对象**   | by-id,绑的是 **`'rec_1'`**                                        |
+
+  最后一格是这次修复里唯一「判定不变、绑定值变了」的一格 —— 前后都是 `by-id`,
+  变的是哪一个 id 源胜出。`ENGINE_UPDATE_DISPATCH_CASES` 因此新增可选的
+  `expectId`,把落进主键位的值本身也钉住,避免用例因为「什么都没产出」而绿。
+
+  **「无 `multi` 的非标量 `data.id`」被明确定成响亮拒绝**,不会静默升级成一次真的
+  批量写 —— 这是裁决(维护者 2026-08-06)对方案 B 那条顾虑的处置:把算子对象写进
+  载荷大概率是写错了位置,那就报错,而不是替作者决定他想批量写。
+
+  无 API 变更:导出符号、类型与 `ENGINE_UPDATE_REJECT_MESSAGE` 的文案均不变。
+
+- 909895d: perf(objectql): `update()` 的单 id 前置行读取改为按对象判定需求(#5284)
+
+  单记录 `update()` 在写入前会读一次「前置行」(`driver.findOne`),用于对象校验规则、
+  `readonlyWhen` 剥离、`hookContext.previous`,以及 roll-up 汇总的旧父记录重算。这道门
+  以前问的是 `this.hooks.get('afterUpdate').length > 0` —— **全部对象汇总在一起**的注册
+  列表。于是只要有**任意一个**对象被观察,平台上**每一个**对象的**每一次**单 id update 都
+  要多付一次数据库往返。同文件的批量路径早就按对象问同一个问题(`hasHooksFor`,#5038),
+  一个文件里存在两种精度。
+
+  现在按对象问,需求项恰好三条,全部是 `priorRecord` 在这条分支上的真实消费方:
+
+  - `needsPriorRecord(schema)` —— 对象校验规则(ADR-0020 的 state_machine / cross_field /
+    script;PATCH 只带变更字段)以及它涵盖的 `readonlyWhen` / `requiredWhen` / 选项可见性;
+  - **本对象**存在 `afterUpdate` hook(`'*'` / 全局注册照样算,`hasHooksFor` 与
+    `triggerHooks` 的过滤逻辑一致)—— 它的 handler 与声明式 `condition` 都读 `previous`;
+  - 本对象被某个 roll-up `summary` 聚合 —— `previous` 携带**旧的**父记录 id,子记录改挂父
+    记录时要同时重算两个父。
+
+  **省下多少取决于 hook 怎么注册,不取决于有多少个。** 按对象注册的那些(record-change flow
+  trigger、plugin-sharing 的按规则重算、plugin-auth 的 `sys_user` 快照刷新、所有元数据编写的
+  hook)从此不再向邻居收税;而**完全不带 `object`** 的注册(plugin-audit 的 `writeAudit`、
+  service-storage 的文件引用回收)本来就会在每个对象上真的执行,所以在装了它们的部署里这道门
+  依然恒真、省不下读 —— 让这两处在注册面上表达它们 handler 里已经在做的过滤,是 #5846,不在
+  本次改动内。
+
+  **正确性保证不变。** `previous` 的语义、fail-loud 的形态(#4775:求不出值即拒绝,绝不
+  伪造 `{}`/`null`)、after-hook 的分发都与之前完全一致;有 `afterUpdate` 的对象付的读一次
+  不少。变的只是**没有任何消费方**的对象不再替别人付账。
+
+  顺带修掉一个此前只是**偶然**成立的行为:子记录改挂父记录时的「旧父重算」依赖的正是这次
+  读,而在一个没有任何 `afterUpdate` hook 的部署里它本来就不会发生(旧父的汇总值静默过期)。
+  roll-up 现在自己声明这项需求,不再靠别的对象的 hook 捎带。
+
+  `beforeUpdate` **不**计入这道门,这是它与 `delete()`(#5272)唯一不对称的地方,原因是两条
+  路径的读取时机不同:`delete()` 在派发 `beforeDelete` **之前**读前置行并绑定,before 阶段
+  因此是真实读者;`update()` 先派发 `beforeUpdate`(它还可能改写这次读要比对的 payload),
+  `hookContext.previous` 要到写入之后才绑定 —— 所以在这条路径上 `beforeUpdate` 无论门怎么
+  判都看不到 `previous`,计入它只会买一次没有读者的读。这一点由测试直接测量钉住。
+
+- 2b52bc8: fix(objectql): a write response is a record, so it carries the record's `formula` fields (#5504)
+
+  `POST /data/:object` and `PATCH /data/:object/:id` answered with the stored
+  document, in which a `formula` field is not `null` but **absent** — formulas are
+  virtual, so no driver ever returns a column for one. The very next `GET` of the
+  same row carried every one of them. Read-your-write was broken in the direction
+  that is hardest to notice: the response calls itself `record`, so consumers
+  render it directly, and every object whose `nameField` points at a formula
+  rendered blank until a second round-trip.
+
+  Cause: `applyFormulaPlan` had exactly two call sites — the `find` result and the
+  `findOne` result. The write paths returned the driver's row untouched, and the
+  REST layer passed it straight through.
+
+  **What changed.** `engine.insert` and `engine.update` now hydrate formula
+  virtuals onto what they hand back, using the _same_ plan builder and the _same_
+  evaluation the read path uses — one formula semantic, not a write-path dialect.
+  Evaluation runs against the row the driver already returned (`create` uses
+  `RETURNING *`, `update` re-reads), so there is no extra round-trip and no
+  formula sees a partial record. Execution context is threaded exactly as `find`
+  threads it today.
+
+  Covered by construction, not per call site: single insert, batch insert,
+  `insertMany` / `createManyData` / `insertManyData`, and single-id update all
+  flow through the one hydration point on each verb. A **predicate** (`multi`)
+  update is unchanged — `driver.updateMany` resolves to an affected-row COUNT and
+  names no row, so it has no record to materialize.
+
+  Ordering, both halves pinned by tests:
+
+  - **after** the write-path strips and refusals — a formula reading a stripped
+    `autonumber` (#5503) or `readonly` (#2948) field reports what was STORED, and
+    a write refused under `strictReadonlyWrites` (#5126) produces no response to
+    hydrate at all;
+  - **before** the `afterInsert` / `afterUpdate` dispatch, mirroring the read
+    path's `applyFormulaPlan` → `afterFind` order, so an after-hook observes the
+    same complete record on a write that it observes on a read.
+
+  Cost is gated exactly as on the read path: an object that declares no formula
+  builds an empty plan and evaluates nothing.
+
+  No API or schema change — a response that was missing keys now has them.
+  Consumers that worked around this with an extra `GET` after every write can drop
+  it; consumers that treated the absent key as "field not configured" should note
+  that an unevaluable formula is reported as `null`, as it always has been on read.
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [64cd010]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [c497d26]
+- Updated dependencies [e96ad55]
+- Updated dependencies [bbdbf28]
+- Updated dependencies [2e284b2]
+- Updated dependencies [75bb3af]
+- Updated dependencies [43ca399]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [533a0a4]
+- Updated dependencies [1f82d1e]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [b746aa0]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [3133cda]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c794f78]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [0f17114]
+- Updated dependencies [ecc61ab]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [db0d53c]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [2b2175b]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [58f3220]
+- Updated dependencies [07f1822]
+- Updated dependencies [729a43a]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [08f93bc]
+- Updated dependencies [d9971d3]
+- Updated dependencies [eb3e650]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [02dc076]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [65159ae]
+- Updated dependencies [95b4f0d]
+- Updated dependencies [877545c]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [444a07c]
+- Updated dependencies [288e5a4]
+- Updated dependencies [46365ab]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [b5459bc]
+- Updated dependencies [1624f4a]
+- Updated dependencies [e6db317]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [c5adfe1]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [da538b1]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [79822b5]
+- Updated dependencies [15e61fb]
+- Updated dependencies [72bd873]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [dde9202]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [bf1edef]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5ab0842]
+- Updated dependencies [5c94f83]
+- Updated dependencies [d275c10]
+- Updated dependencies [73e576f]
+- Updated dependencies [1d29e6d]
+- Updated dependencies [c5a5996]
+- Updated dependencies [5ea8e1e]
+- Updated dependencies [51a587d]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [dca25e1]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [e92e2c3]
+- Updated dependencies [946a131]
+- Updated dependencies [38f53a0]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/types@17.0.0-rc.4
+  - @objectstack/core@17.0.0-rc.4
+  - @objectstack/metadata-protocol@17.0.0-rc.4
+  - @objectstack/metadata@17.0.0-rc.4
+  - @objectstack/formula@17.0.0-rc.4
+  - @objectstack/metadata-core@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Major Changes
diff --git a/packages/objectql/package.json b/packages/objectql/package.json
index 4ba639c759..73ed79c20d 100644
--- a/packages/objectql/package.json
+++ b/packages/objectql/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/objectql",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "Isomorphic ObjectQL Engine for ObjectStack",
   "main": "dist/index.js",
diff --git a/packages/observability/CHANGELOG.md b/packages/observability/CHANGELOG.md
index adf9c4d822..bc1eecebf4 100644
--- a/packages/observability/CHANGELOG.md
+++ b/packages/observability/CHANGELOG.md
@@ -1,5 +1,126 @@
 # @objectstack/observability
 
+## 17.0.0-rc.4
+
+### Patch Changes
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [d9971d3]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Patch Changes
diff --git a/packages/observability/package.json b/packages/observability/package.json
index 1db2caedab..4aa15efec4 100644
--- a/packages/observability/package.json
+++ b/packages/observability/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/observability",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "Observability contracts and exporters for ObjectStack — MetricsRegistry, ErrorReporter, Logger plus noop/console/OTLP-HTTP exporters. Deployment-target neutral; runtime and services depend on this so the same instrumentation works on Cloudflare Workers, Node, and self-hosted Kubernetes.",
   "type": "module",
diff --git a/packages/platform-objects/CHANGELOG.md b/packages/platform-objects/CHANGELOG.md
index d1a899f072..86cf01be20 100644
--- a/packages/platform-objects/CHANGELOG.md
+++ b/packages/platform-objects/CHANGELOG.md
@@ -1,5 +1,277 @@
 # @objectstack/platform-objects
 
+## 17.0.0-rc.4
+
+### Minor Changes
+
+- e98fb14: fix(service-queue): `sys_job_queue` no longer grows forever — `completed` rows expire on a declared 7-day retention (#5179)
+
+  `DbQueueAdapter` marked a delivered message `status: 'completed'` and then
+  **nothing ever touched that row again**. `purge()` had zero production callers
+  (tests only), `purgeFailed()` is a manual dead-letter API, and the object
+  declared no lifecycle policy at all — so every queue delivery left a permanent
+  row, which since #5160 means one permanent row per queued email.
+
+  `sys_job_queue` now declares an ADR-0057 policy and the platform
+  `LifecycleService` enforces it on its existing hourly sweep:
+
+  ```ts
+  lifecycle: {
+    class: 'transient',
+    retention: { maxAge: '7d', onlyWhen: { status: 'completed' } },
+  }
+  ```
+
+  **Only `completed` rows are swept.** `pending` / `running` are live work, and
+  `failed` / `dlq` are the dead-letter queue — they exist to wait for a human, so
+  they are never deleted automatically at any age. `listFailed()` / `replay()` /
+  `purgeFailed()` remain the only way a dead letter leaves the table. This is
+  also why the policy is `retention` (age + row filter) rather than a `ttl` on
+  `completed_at`: TTL has no row filter, and `dlq` rows stamp `completed_at` too.
+
+  **No new configuration, and no new sweeper.** ADR-0057 §3.3 puts one reaper in
+  the platform rather than one per plugin — the same call the sibling
+  `sys_job_run` (30d) already makes. Any kernel with a data engine already runs
+  it, its per-sweep `[lifecycle] sweep: … ~N rows reaped` line now accounts for
+  this table too, and the window is overridable per environment through the
+  `lifecycle` settings namespace without touching code.
+
+  **The dedup window is now an enforced invariant, not a coincidence.** Publish
+  dedups against a terminal row by comparing its `created_at` to
+  `idempotencyWindowMs` (default 24h), and the reaper cuts off on that same
+  `created_at` axis — so retention (7d) ≥ dedup window is what keeps "duplicate
+  publishes inside the window are suppressed" true. `DbQueueAdapter` reads the
+  declared window (new export `completedRetentionWindowMs()`) and **throws at
+  construction** if `idempotencyWindowMs` is configured longer than it, instead of
+  silently degrading into duplicate deliveries days later. If you raise
+  `idempotencyWindowMs` past 7 days, raise the object's declared retention (or the
+  `lifecycle` settings override) to match — the error message names both numbers.
+
+  `class: 'transient'` is deliberate: `telemetry`/`event`/`audit` classes
+  relocate their table to the dedicated `telemetry` datasource wherever one is
+  registered (ADR-0057 §3.6), and moving a live work queue's storage would be a
+  migration, not a cleanup.
+
+- f104bab: feat(plugin-email,platform-objects): `sys_email` carries headers and small attachments, so those messages become durably deliverable (#5177)
+
+  Durable email delivery works from the **row**, not from the in-memory message:
+  `send()` publishes an `{ rowId }` job (#5160), the boot sweep re-reads rows
+  (#5161), and both end at `rowToNormalized`. So anything a `sys_email` row could
+  not carry, a row-based delivery would have dropped — and custom headers and
+  attachments were exactly that. The honest workaround was to refuse: a message
+  with either was pushed back onto inline delivery so that it would at least go
+  out whole, which closed the durable path to precisely the mail most worth
+  making durable (a signed receipt, a `List-Unsubscribe` header, an invoice PDF).
+
+  `sys_email` now has two columns, and those messages are queueable.
+
+  **`headers_json`** — the custom headers, as a JSON object. Written in both
+  delivery modes (it is audit evidence as much as delivery input) and rebuilt on
+  read. Headers are no longer a reason to fall back to inline delivery.
+
+  **`attachments_json`** — attachments as a JSON array of
+  `{ filename, contentType?, size, hash, cid?, contentForm, inline?, storageKey? }`,
+  content base64 in `inline`. Written when the **combined raw size of one
+  message's attachments is within `SYS_EMAIL_ATTACHMENT_LIMIT_BYTES` (256 KiB,
+  exported from `@objectstack/plugin-email`)** — worst case ~350 KB of base64, so
+  a row stays bounded. Both arms of the declared `content: string | Buffer`
+  contract round-trip as the arm they were sent as: restoring a text attachment
+  as a Buffer would silently drop `charset=utf-8` from its MIME part and let the
+  recipient's client mis-decode a UTF-8 file, so `contentForm` records which one
+  it was. `cid` travels too — an inline `<img src="cid:…">` is unusable without
+  it.
+
+  **Over the limit, nothing changes.** The message is delivered inline exactly as
+  before, whole, and the row stores no attachment content; the reason is stated
+  at `info` (a bound, not a degradation — the worst outcome is today's
+  behaviour). Out-of-row storage for large attachments is #5172; `storageKey` is
+  declared now so that lands as a new _producer_ rather than a data migration.
+
+  Rows written before these columns exist read exactly as they did. A column that
+  is present but does not describe what it claims — malformed JSON, a size or
+  hash that disagrees with the content, a missing `contentForm` — is **rejected**,
+  and the row lands at `failed` carrying the reason, rather than being delivered
+  with a part quietly missing.
+
+  The `sys_email` schema change is additive (two optional textarea columns); no
+  migration is required and default inline delivery is unchanged.
+
+### Patch Changes
+
+- f1cc3a3: fix(spec): stop offering retired `app` keys in the metadata form, and make the reconciliation gate see tombstones (#5280)
+
+  The `app` authoring form rendered **eight** controls for keys `AppSchema` had
+  already retired to `retiredKey()` tombstones in 17.0.0 — `version`, `homePageId`,
+  `objects`, `apis`, `sharing`, `embed`, `mobileNavigation` and `aria`. A tombstone
+  is `z.never().optional()`, so filling one of those controls did not lose the
+  value quietly: it failed the **entire save** with the key's removal
+  prescription. The controls are gone, each with a comment in place naming where
+  the capability went (`manifest.version`; the first `navigation` item by `order`
+  plus `isDefault`; `defineStack({ objects })`; `defineStack({ apis })`;
+  `FormView.sharing` for both public access and embedding; the component that
+  renders the DOM node for `aria`).
+
+  Nothing about the contract changes — every one of these keys was already
+  rejected at parse. What changes is that an author is no longer shown a control
+  that can only produce a 422.
+
+  **The reconciliation gate now judges the right thing.** #3786's
+  `metadata-form-zod-reconciliation.test.ts` asked whether an offered key was
+  `∈ shape`. That was the same question as "may the author write this" until
+  `retiredKey()` existed: a tombstone **deliberately stays in the shape** so the
+  removal can carry its own upgrade prescription, so every one of those eight keys
+  read as "the Zod accepts it" and the gate stayed green over all of them. It now
+  asserts `∈ shape` **and not a tombstone**, in both directions — a retired key
+  may not be offered, and its absence needs no ledger entry to excuse it. The
+  detector reads the schema node (`z.never()` under the optional wrapper), never a
+  list of key names, mirroring `isRetired()` on the JSON-Schema side of
+  `build-schemas.ts`. The next `retiredKey()` retirement that forgets a form now
+  fails this test instead of reaching an author.
+
+  Retiring an authorable key already required pruning its form input; that step is
+  now enforced rather than remembered.
+
+- eda599e: fix(platform-objects): 超预算后台 seed 期间不再空库自证 —— 一次启动不再跑两套契约
+
+  #4769 已把 ADR-0104 的空库自证从 `kernel:ready` 挪到 `app:seeded`(本次启动自身数据的结算点),但保留 `kernel:ready` 作为「从不 seed 的内核」的兜底。剩下的窗口是这两个钩子**到达顺序可以颠倒**:`AppPlugin` 的 inline seed 超出软预算(`OS_INLINE_SEED_BUDGET_MS`,默认 8s)后转入后台,于是 `kernel:ready` 先到、兜底自证在 seed 仍在写的时候签发证书并把闸门翻到 strict——同一次 seed 运行的后半段撞上前半段从未见过的契约。showcase 冷启(`OS_INLINE_SEED_BUDGET_MS=1`)实测:自证发生在 +0.470s,seed 结算在 +3.617s,窗口 3.147s。
+
+  现在两个钩子都先问一句「本次启动自己的 seed 落定了吗」,任一处报告仍有未结算的 seed 源就不签发。`app:seeded` 同样受这道检查约束——多 config app 的 bundle 会每个 app 触发一次,第一次并不是本次启动的结算点。
+
+  新增 `seed-settlement` 契约(`@objectstack/spec/contracts`)承载这个信号,而不是让 platform-objects 去嗅 runtime 内部的 `seed-datasets` 服务:那个数组的存在只能说明「seed 源存在」,永远说明不了「已经落定」,而这两件事之间的差正是本 bug 的整个窗口。runtime 在选择分支之前先声明 seed 源,并在写入真正结束的同一刻结算它。
+
+  **multi-tenant 与 `skipSeedData` 的 ADR-0104 姿态(2026-08-06 裁定,#4795)**:这两种部署会注册 seed 数据但在启动时并不写入(前者按 org 在 `sys_organization` insert 时重放,后者是 `os migrate` 的只读规划启动,#3917),`app:seeded` 永不触发。它们的姿态是**启动时不自证,等 `os migrate … --apply` 在真实扫描的证据上落笔**——由同一个判据自然得出,不需要单独分支。这是答案而不是缺口:在启动那一刻断言一次尚未发生的 per-org 重放不含违规值,正是 #4769 的同一个错误、只是引信更长;而停在 warn-first 是可恢复的方向,随时可由 `os migrate value-shapes --apply` / `os migrate files-to-references --apply` 关闭。
+
+  `@objectstack/objectql` 侧只更新了 #4769 撤销机制的注释:「后台 seed 收尾晚于签发」不再是它要兜的场景(已在源头关闭),它对 `os dev` 热重载 seeder、运行期 marketplace 安装以及 lax 开关仍然有效。
+
+- 1b9a53b: plugin-email: large attachments (>256 KiB) now get durable queue delivery, with their content held out of the `sys_email` row
+
+  A message whose attachments exceeded the in-row budget was pushed back onto inline delivery — whole, but with none of the durability queue delivery exists to provide, which meant the platform was weakest about exactly the mail that matters most (a signed contract, an exported report). Its content now goes to the `file-storage` capability, the row records a `storageKey` plus the audit metadata, and the queue worker fetches the content back to rebuild the message.
+
+  - **Zero migration.** `attachments_json` declared `storageKey` from the start; this adds the producer and the reader. Attachments at or under `SYS_EMAIL_ATTACHMENT_LIMIT_BYTES` still go in the row exactly as before, and the boundary includes equality.
+  - **The row stays an audit log, not a blob store.** `filename` / `contentType` / `size` / `hash` stay on the row permanently; the content is a delivery artifact and is deleted a grace window (24h) after the row reaches a terminal state, at which point `storageKey` is replaced by `contentReclaimedAt`. Reclamation is a delayed `email.attachment.reclaim` queue job that carries the storage keys, so a row deleted in the meantime reclaims its content instead of orphaning it.
+  - **Nothing degrades silently.** No `file-storage` capability, or an upload that fails, keeps today's behaviour — inline delivery of the whole message — and says which of the two it was and how to fix it. On the way back, content that cannot be fetched (outage, missing object, no capability on the worker, truncated or substituted bytes) fails the row loudly; a message is never delivered without an attachment it declares.
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [db0d53c]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [d9971d3]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [51a587d]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [946a131]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/metadata-core@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Minor Changes
diff --git a/packages/platform-objects/package.json b/packages/platform-objects/package.json
index 8b75581d5d..b0c0002a1a 100644
--- a/packages/platform-objects/package.json
+++ b/packages/platform-objects/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/platform-objects",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "Core platform object schemas for ObjectStack — identity, security, audit, tenant, and metadata objects",
   "main": "dist/index.js",
diff --git a/packages/plugins/embedder-openai/CHANGELOG.md b/packages/plugins/embedder-openai/CHANGELOG.md
index 6da45ad4af..6bd5a48e4c 100644
--- a/packages/plugins/embedder-openai/CHANGELOG.md
+++ b/packages/plugins/embedder-openai/CHANGELOG.md
@@ -1,5 +1,126 @@
 # @objectstack/embedder-openai
 
+## 17.0.0-rc.4
+
+### Patch Changes
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [d9971d3]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Patch Changes
diff --git a/packages/plugins/embedder-openai/package.json b/packages/plugins/embedder-openai/package.json
index e968605a01..3b43c18363 100644
--- a/packages/plugins/embedder-openai/package.json
+++ b/packages/plugins/embedder-openai/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/embedder-openai",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "OpenAI-compatible embedder for ObjectStack — works against OpenAI, 阿里通义 DashScope, 智谱 BigModel, 硅基流动 SiliconFlow, 火山引擎 Doubao, MiniMax, Ollama, and any drop-in OpenAI-shape endpoint.",
   "main": "dist/index.js",
diff --git a/packages/plugins/knowledge-memory/CHANGELOG.md b/packages/plugins/knowledge-memory/CHANGELOG.md
index d92de2cd50..24585a178e 100644
--- a/packages/plugins/knowledge-memory/CHANGELOG.md
+++ b/packages/plugins/knowledge-memory/CHANGELOG.md
@@ -1,5 +1,136 @@
 # @objectstack/knowledge-memory
 
+## 17.0.0-rc.4
+
+### Patch Changes
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [b746aa0]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [d9971d3]
+- Updated dependencies [eb3e650]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [44106d9]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [46365ab]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [c5adfe1]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/core@17.0.0-rc.4
+  - @objectstack/service-knowledge@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Patch Changes
diff --git a/packages/plugins/knowledge-memory/package.json b/packages/plugins/knowledge-memory/package.json
index 993e0f4f8d..4aab115135 100644
--- a/packages/plugins/knowledge-memory/package.json
+++ b/packages/plugins/knowledge-memory/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/knowledge-memory",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "In-memory knowledge adapter for ObjectStack (dev / test reference implementation).",
   "main": "dist/index.js",
diff --git a/packages/plugins/knowledge-ragflow/CHANGELOG.md b/packages/plugins/knowledge-ragflow/CHANGELOG.md
index 4a95c21038..3c8f4f0c25 100644
--- a/packages/plugins/knowledge-ragflow/CHANGELOG.md
+++ b/packages/plugins/knowledge-ragflow/CHANGELOG.md
@@ -1,5 +1,136 @@
 # @objectstack/knowledge-ragflow
 
+## 17.0.0-rc.4
+
+### Patch Changes
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [b746aa0]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [d9971d3]
+- Updated dependencies [eb3e650]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [44106d9]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [46365ab]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [c5adfe1]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/core@17.0.0-rc.4
+  - @objectstack/service-knowledge@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Patch Changes
diff --git a/packages/plugins/knowledge-ragflow/package.json b/packages/plugins/knowledge-ragflow/package.json
index f34ed58882..0020a592f3 100644
--- a/packages/plugins/knowledge-ragflow/package.json
+++ b/packages/plugins/knowledge-ragflow/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/knowledge-ragflow",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "RAGFlow knowledge adapter for ObjectStack — production-grade RAG via the Apache 2.0 RAGFlow REST API.",
   "main": "dist/index.js",
diff --git a/packages/plugins/plugin-approvals/CHANGELOG.md b/packages/plugins/plugin-approvals/CHANGELOG.md
index 0427d1b5e4..91fdc6f531 100644
--- a/packages/plugins/plugin-approvals/CHANGELOG.md
+++ b/packages/plugins/plugin-approvals/CHANGELOG.md
@@ -1,5 +1,287 @@
 # @objectstack/plugin-approvals
 
+## 17.0.0-rc.4
+
+### Minor Changes
+
+- ddc2527: fix(approvals): the ADR-0044 revise window is a service-owned node type, not a bare `wait` (#3823)
+
+  #3801 gated `POST /api/v1/automation/:name/runs/:runId/resume` on the **node type**
+  that produced the suspension: an `approval` pause declares
+  `resumeAuthority: 'service'`, so it continues only through `ApprovalService`.
+  ADR-0044's **revise window** was the same trust boundary in a shape that key
+  could not see. Send-back parked the run on an ordinary `wait` node the flow
+  author placed — correctly `resumeAuthority: 'any'`, because a signal wait is
+  _meant_ to be resumable by an external producer — and `ApprovalService.resubmit`
+  was the only thing that checked anything about continuing it.
+
+  Demonstrated (not reasoned) against the real engine: a raw `resume(runId)` with
+  an **empty body**, from any caller, walked the `resubmit` back-edge into the
+  approval node and opened round N+1 with **no submitter check and no `resubmit`
+  audit row** (`['submit','revise']` — no third row, ever). Worse, when another
+  request was already pending on the record — the exact case `resubmit` refuses
+  with `DUPLICATE_REQUEST` _specifically to keep the run alive_ — the raw resume
+  went around that guard: the approval node's re-entry failed **after** the engine
+  consumed the suspension, and the run was **permanently destroyed** with its
+  round-N request stuck `returned` and no resubmit able to reach it.
+
+  The revise pause is therefore its own node type:
+
+  - **`approval_revise`** (`APPROVAL_REVISE_NODE_TYPE`), registered by
+    `@objectstack/plugin-approvals` alongside the `approval` node, declaring
+    `resumeAuthority: 'service'`. It stays a first-class box on the canvas, in the
+    run log and in the suspended-run store — only the _reuse_ of `wait` was wrong.
+    It takes **no config**: the window ends on the submitter's explicit resubmit,
+    never on a signal or timer. The `resumeAuthority` gate itself is unchanged.
+  - `sendBack` refuses a `revise` edge whose target is not an `approval_revise`
+    node, **before any mutation** (like the existing missing-`revise`-edge check),
+    so no run can be parked in a window something else can advance.
+  - New gating lint `flow-approval-revise-target-not-service-owned`
+    (severity `error`, on `os build` / `os validate` / `os lint` and the runtime
+    metadata publish gate) rejects the old shape at authoring time.
+
+  **Upgrading a flow authored against the original ADR-0044 D3.** One token:
+
+  - **FROM:** `{ id: 'wait_revision', type: 'wait', waitEventConfig: { eventType: 'signal', … } }`
+  - **TO:** `{ id: 'wait_revision', type: 'approval_revise' }` — drop
+    `waitEventConfig` / any `config`; the window has no event to wait on.
+
+  Until you do, such a flow keeps registering and running and its approvals stay
+  decidable (`approve` / `reject` / `recall` / `reassign` are untouched), but
+  **send-back is refused** with a message naming the node and this fix, and
+  re-publishing it reports the lint error. A run _already parked_ in a legacy
+  revise window keeps its recorded node type (a republish never re-types a live
+  pause) and is drained by `resubmit` or `recall` as usual.
+
+  ADR-0044's 2026-07-28 amendment records the reversal of its D3 and of its
+  `Alternatives` rejection of a service-owned revise pause, with the evidence
+  above; the implementation section there records what shipped, why the approval
+  node does not re-suspend itself instead, and why no ADR-0087 conversion was
+  added for the old shape.
+
+### Patch Changes
+
+- 7e5ac28: fix(approvals): 删除两处读 `session.roles` 的 admin 豁免 —— 记录锁与委托守卫回到单一权限词汇 (#4839)
+
+  `plugin-approvals` 的 `lifecycle-hooks.ts` 里有两处 admin 豁免,都读
+  `ctx.session.roles`:审批**记录锁**的 `bindApprovalLockHook`,以及
+  `sys_approval_delegation` 的 `bindDelegationWriteGuard`。两处都已删除。
+
+  **这不是行为变更。** `session.roles` 在整个平台没有生产者 —— ObjectQL 的
+  `buildSession()` 逐字段构造 session,从不写 `roles` —— 所以两个分支在任何真实引擎
+  路径上都是死代码,记录锁一直就对 admin 生效,委托一直就只能本人管理。删除让代码
+  说出运行时本来就在做的事(spec 的 `HookContext` 声明了 `roles`,消费方在读,生产方
+  从不写:典型的 declared ≠ enforced)。
+
+  **为什么不是「改用正确判据」而是删除。** `roles.includes('admin')` 还是第二套权限
+  方言:本仓库的权限一律由 ADR-0095 词汇裁决(能力授予 `permissions`、任职
+  `positions`、由其派生的 posture),ADR-0090 D3 更是直接禁掉 `role` 这个拼法。同包的
+  `ApprovalService.isOverrideActor` 已经这么做了。维护者裁定两处都取「删除」而非改判据:
+
+  - **记录锁**:admin 释放锁定记录的正规路径已经存在(#3424 —— `recall` /
+    `decideNode` 驳回 / `reassign`,全部由 `isOverrideActor` 把关并留痕
+    `via_override`)。让审批终结来释放锁,记录就永远不会在审批在途时被改写 —— 这正是
+    合规场景购买记录锁所要的保证。
+  - **委托**:最终语义确定为**仅本人管理**(`delegator_id` 必须等于写入者;只有 system
+    上下文旁路)。审批人临时不可用时,替他处置**在途**审批用的是
+    `reassign`(把该审批人的名额交给替代人,连 per_group 分组归属一起带过去)/
+    `recall` / 驳回。反过来,「替别人建一条委托」本来也做不到这件事:委托只在请求
+    **开启**时(`resolveApproverSpec` 内的 `applyOooDelegation`)被查询,对已经挂在该
+    审批人名下的在途审批毫无作用。
+
+  新增 `admin-exemption-retired.test.ts`,把上述证据变成可执行断言,并加了一道源码级
+  pin:本包非测试源码中不得再出现 `roles` 标识符或与字符串 `'admin'` 的比较。
+
+  spec 侧 `session.roles` 的退役(至此零消费方)按 ADR-0049 enforce-or-remove 另立协议
+  单处理,不在本次改动内。
+
+- 19e1a8f: fix(approvals): an approval decision can no longer strand a flow run silently when no automation engine is attached (#4420)
+
+  #4420's fix closed every path by which a decision could be recorded while its
+  flow stayed parked — except one, and it is the one where none of the new guards
+  could run. Every guard it added (`assertRunResumable`'s pre-flight, the
+  `RESUME_TARGET_LOST` refusal, the `RESUME_FAILED` throw) hangs off the
+  automation engine. In a process where **no engine is attached**, all of them
+  were skipped by the same `typeof this.automation?.resume === 'function'`
+  condition that wrapped the resume itself — so the decision was written, the
+  mirrored status field advanced, and the call answered HTTP 200 with
+  `resumed: false` and **nothing logged at all**. That is #4420's reported
+  symptom exactly, reproduced in the one composition its fix could not see.
+
+  The composition is reachable the same way the original bug was: a flow parks at
+  an `approval` node in a process that has the automation service, and the
+  decision arrives in one that does not (the plugin failed to init, or the host
+  was recomposed between releases). The request row still carries a
+  `flow_run_id` — which is the row's own declaration that a run is parked on this
+  decision.
+
+  **What changes.** The decision still stands. Rolling it back is not on the
+  table (a human really decided, and the row is durable by then), and refusing
+  every such call would break the standalone approvals compositions the
+  pre-flight deliberately protects — so `finalized` and `resumed` are unchanged
+  for every existing caller. What changes is that the gap is no longer silent:
+
+  - it is logged at **`error`**, per the durability rule in `AGENTS.md` —
+    persisted state and runtime state disagree while nothing looks broken from
+    the outside, which is the class that rule exists for;
+  - the response carries **`resumeError`**, so `resumed: false` arrives with its
+    reason and the stranded run's id instead of leaving the caller to guess
+    whether a resume was even attempted.
+
+  It reuses the already-registered `RESUME_FAILED` code and the existing resume
+  message shape rather than introducing a new vocabulary — the fact being
+  reported (an outcome recorded whose run did not advance) is the same one.
+
+  Applied at all five sites that resume a recorded outcome: `decide`, the
+  revision-limit auto-rejection, `sendBack`, `resubmit`, and both branches of
+  `recall` (whose revise-window path needs `cancelRun` rather than `resume`).
+
+  A request that names **no** run is unaffected and stays quiet — there is
+  nothing parked on it, and reporting one there would be the mirror-image
+  failure that trains operators to skim `error`.
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [64cd010]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [b746aa0]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [0f17114]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [db0d53c]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [58f3220]
+- Updated dependencies [07f1822]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [08f93bc]
+- Updated dependencies [d9971d3]
+- Updated dependencies [eb3e650]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [02dc076]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [e98fb14]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [1b9a53b]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [46365ab]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [c5adfe1]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [bf1edef]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [51a587d]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [f104bab]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [946a131]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/types@17.0.0-rc.4
+  - @objectstack/core@17.0.0-rc.4
+  - @objectstack/platform-objects@17.0.0-rc.4
+  - @objectstack/formula@17.0.0-rc.4
+  - @objectstack/metadata-core@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Minor Changes
diff --git a/packages/plugins/plugin-approvals/package.json b/packages/plugins/plugin-approvals/package.json
index 9ec6874699..dbe132aa22 100644
--- a/packages/plugins/plugin-approvals/package.json
+++ b/packages/plugins/plugin-approvals/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/plugin-approvals",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "Multi-step approval engine for ObjectStack — sys_approval_process + sys_approval_request + sys_approval_action + IApprovalService.",
   "main": "dist/index.js",
diff --git a/packages/plugins/plugin-audit/CHANGELOG.md b/packages/plugins/plugin-audit/CHANGELOG.md
index 6148094880..681dc586fb 100644
--- a/packages/plugins/plugin-audit/CHANGELOG.md
+++ b/packages/plugins/plugin-audit/CHANGELOG.md
@@ -1,5 +1,256 @@
 # @objectstack/plugin-audit
 
+## 17.0.0-rc.4
+
+### Patch Changes
+
+- c5e7bd9: fix(plugin-audit): say where the audit system tables were provisioned, and stop skipping provisioning silently (#4887)
+
+  `AuditPlugin.provisionSystemTables()` created `sys_audit_log` / `sys_activity` /
+  `sys_comment` at `kernel:ready` and then said **nothing** — not on success, and
+  not when it skipped the work entirely (`typeof engine.syncObjectSchema !==
+'function'` returned silently). `syncObjectSchema()` itself returns `void` and
+  has three silent exits of its own — the object is not in the registry, no driver
+  resolves for it, or the resolved driver has no `syncSchema` — none of which
+  throw. So "provisioned three tables" and "provisioned nothing at all" produced
+  byte-identical logs, and the only way to tell them apart was to go looking in a
+  database.
+
+  #4887 is what that costs. `sys_audit_log` and `sys_activity` were reported as
+  never provisioned because they were absent from the primary SQLite file, with
+  the silent `typeof` bail named as the likely cause. Neither was true:
+  `sys_audit_log` (`lifecycle.class: 'audit'`) and `sys_activity`
+  (`lifecycle.class: 'telemetry'`) are routed by **ADR-0057 §3.6** to the
+  dedicated `telemetry` datasource whenever one is registered, and `os dev`
+  registers one by default as a _sibling file_ (`dev.db` → `dev.telemetry.db`).
+  Both tables had been created — in the other store. `sys_comment` carries no
+  lifecycle class, stays on the primary, and was the one that "existed". Nothing
+  in the log connected those three facts.
+
+  Provisioning now reports itself:
+
+  - **Wholesale skip is a `warn`, naming the consequence** — the tables stay
+    lazy-created on first WRITE, so an env that READS one first (the home page
+    activity feed queries `sys_activity` before any mutation) logs "no such
+    table" until something writes.
+  - **One `info` line per boot listing where each table landed** —
+    `sys_audit_log→telemetry, sys_activity→telemetry, sys_comment→sqlite`,
+    resolved through the engine's own `getDriverForObject`, so the log states the
+    routing rather than leaving it to be inferred.
+  - **A second `info` line when the ADR-0057 split is in effect**, saying
+    explicitly that those tables live in a different store — on SQLite, a
+    different _file_ — and that anything reading them without naming the object
+    (raw SQL against the default datasource) will report "no such table" even
+    though provisioning succeeded.
+  - **An object that resolves to no driver is a `warn`** — `syncObjectSchema()`
+    returns without issuing any DDL in that case and throws nothing, so the
+    per-object `catch` never fires; from outside the engine this is the only place
+    it can be observed.
+
+  Behaviour is otherwise unchanged: the same three objects are synced, per-object
+  failures stay isolated, and an engine without on-demand DDL still degrades
+  instead of failing `start()`.
+
+- 0162c81: fix(plugin-audit): stop mirroring `sys_job_queue` traffic into the audit ledger (#5193)
+
+  `SKIP_OBJECTS` in `audit-writers.ts` excludes operational telemetry / plumbing
+  from `sys_audit_log` and `sys_activity` — ADR-0057 decision 5, _"stop the
+  amplifier"_. Its group (2) already listed `sys_job`, `sys_job_run` and
+  `sys_automation_run`; `sys_job_queue` — the highest-volume table of that same
+  family — was the one sibling missing, so every durable queue message was
+  mirrored into both sinks.
+
+  The audit hooks register for **all** objects (`afterInsert` / `afterUpdate` /
+  `afterDelete`) and there is no "writes made under a system context are not
+  audited" exemption, so `DbQueueAdapter`'s own writes were recorded like user
+  edits. One message costs at least three of them — the publish insert, the lease
+  `pending → running` update and the terminal `→ completed` update, plus one retry
+  update per failure and the reaper's periodic DELETE of completed rows — each
+  producing an `sys_audit_log` **and** an `sys_activity` row. Since queue-backed
+  email delivery landed, that ran on every single mail. Each `beforeUpdate` also
+  paid an extra `findOne` snapshot of the row it was about to change.
+
+  `sys_job_queue` is engine-owned plumbing (`managedBy: 'engine-owned'`,
+  `enable.apiMethods: ['get', 'list']`, `lifecycle.class: 'transient'`) that no
+  user can write, so those rows carried no compliance value — only noise and write
+  amplification. Nothing else changes: the exemption is one name in one list, and
+  ordinary business objects are audited exactly as before.
+
+  Operators who charted queue throughput off `sys_activity` should read
+  `sys_job_queue` directly instead — it is the system of record for queue state,
+  and unlike the audit sinks it is exposed for reading (`get` / `list`).
+
+- 055f0c9: fix(plugin-audit): stop mirroring chunked-upload progress into the audit ledger (#5202)
+
+  `SKIP_OBJECTS` in `audit-writers.ts` excludes operational telemetry / plumbing
+  from `sys_audit_log` and `sys_activity` — ADR-0057 decision 5, _"stop the
+  amplifier"_. `sys_upload_session` was the second table missing from group (2)
+  for the same reason `sys_job_queue` was (#5193): it declares
+  `lifecycle.class: 'transient'` and its own object comment says what the rows are
+  worth — _"an upload session is ephemeral state, never business truth"_
+  (ADR-0057 / #2970 item 4) — but nothing connected that declaration to the
+  exemption list, which is hand-written.
+
+  The audit hooks register for **all** objects and there is no "writes made under
+  a system context are not audited" exemption, so `StorageMetadataStore`'s own
+  writes were recorded like user edits. A chunked upload of N parts costs 1 + N
+  writes — the `createSession()` insert plus one `updateSession()` per chunk — and
+  then a terminal status update and the row's removal, each producing an
+  `sys_audit_log` **and** an `sys_activity` row: 2 × (1 + N) rows for one file,
+  with a `beforeUpdate` snapshot read apiece. Each of those rows was also unusually
+  fat, because `updateSession()` writes the merged **full** record, so the `parts`
+  JSON blob that grows with every chunk rode along in each diff's `old_value` /
+  `new_value`.
+
+  Nothing else changes: the exemption is one name in one list, and ordinary
+  business objects are audited exactly as before. In particular `sys_file` stays
+  audited — it declares `transient` too, but only to reap tombstones and
+  unfinished uploads; its rows are mostly permanent business truth and keep their
+  compliance value.
+
+  Operators who tracked upload activity through `sys_activity` should read
+  `sys_upload_session` (in-progress state) and `sys_file` (the durable record of
+  what was actually stored) instead.
+
+- e18e3da: 审计行写失败改为 `error` 级,并只报一次
+
+  按 AGENTS.md「Degradation log levels」的判据,审计写失败属 **durability / data-consistency** 类而非 functional 类:被审计的那次写入本身成功、数据已落库、接口返回 200,从外面看一切正常,只有记录「谁做的」的 `sys_audit_log` 行没有落地,而且没有任何重试。这正是 #4420 在合规账本上的同一形状,因此原先的 `WARN Audit write failed` 升级为 `error`。
+
+  这条 `error` 同时给出**后果**与**修复方向**:审计轨迹已不完整;`sys_audit_log` 受 ADR-0057 §3.6 生命周期分流,注册了 `telemetry` 数据源时会被路由过去(`os dev` 默认以兄弟 SQLite 文件形式提供一个),所以出现 "no such table" 通常意味着该次写入执行在了与建表处**不同**的数据源连接上;`OS_TELEMETRY_DB=0` 可让所有 lifecycle-classed 对象留在主数据源。
+
+  审计写发生在**每一次**数据变更上,因此该 `error` 全进程**只报一次**(后续失败降为 `debug`,细节仍可通过提高日志级别取回)—— 每次失败都报一遍会训练所有人略过 `error`,而这正是当初让 #4420 的 `warn` 无人阅读的反射。
+
+  写入点提取为具名的 `persistAuditTrailRow`,并登记进 `scripts/check-durability-degradation-log-level.mjs` 的 `DURABILITY_CRITICAL_CALLEES`,由 `pnpm check:durability-log-level` 守住该级别,防止日后被悄悄改回 `warn`。
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [b746aa0]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [d9971d3]
+- Updated dependencies [eb3e650]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [e98fb14]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [1b9a53b]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [46365ab]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [c5adfe1]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [f104bab]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/core@17.0.0-rc.4
+  - @objectstack/platform-objects@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Major Changes
diff --git a/packages/plugins/plugin-audit/package.json b/packages/plugins/plugin-audit/package.json
index 831af33038..e79bc2da8a 100644
--- a/packages/plugins/plugin-audit/package.json
+++ b/packages/plugins/plugin-audit/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/plugin-audit",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "Audit Plugin for ObjectStack — System audit log object and audit trail",
   "main": "dist/index.js",
diff --git a/packages/plugins/plugin-auth/CHANGELOG.md b/packages/plugins/plugin-auth/CHANGELOG.md
index c53632a4fe..e1a7f195ee 100644
--- a/packages/plugins/plugin-auth/CHANGELOG.md
+++ b/packages/plugins/plugin-auth/CHANGELOG.md
@@ -1,5 +1,894 @@
 # Changelog
 
+## 17.0.0-rc.4
+
+### Major Changes
+
+- de113a4: BREAKING(auth): `organization/create` 改判**实际生效的** tenancy posture —— 没有组织墙的部署不再能创建组织 (#5261)
+
+  `POST /api/v1/auth/organization/create` 的闸门此前判的是操作者**请求的** posture
+  (`postureEnforcesWall(resolveTenancyPosture())`,一次纯 env 读)。现在判 `tenancy` 服务给出的
+  **生效** posture —— `tenancy?.posture ?? resolveTenancyPosture()`,与 `/auth/config` 的
+  `features.multiOrgEnabled` 是**同一次求值**。
+
+  ## 为什么
+
+  两个站点此前只在一种形状下分叉,而那种形状恰恰是最不该放行的一种 —— ADR-0093 D5 **降级态**:
+  请求了 `isolated`/`group`,但企业包 `@objectstack/organizations` 缺席,于是 `tenancy.posture`
+  解析为 `single` 且 `degraded=true`。此时:
+
+  - 闸门读「请求」→ **放行**;
+  - `/auth/config` 读「生效」→ `multiOrgEnabled=false`,console 把「创建组织」入口**藏起来**。
+
+  结果是 UI 没有按钮而 API 打得通,并且建出来的每一个组织都是**没有任何引擎强制的租户边界** ——
+  声明了但没强制,ADR-0049 最讨厌的那一类,只不过发生在部署层。改判生效 posture 之后两者同解、
+  永不分叉:**没有墙,就没有组织**,无论这个部署是从未要过墙,还是要了没拿到。
+
+  ## 破坏性影响(有意为之)
+
+  **没有安装企业包 `@objectstack/organizations` 的部署将完全无法创建组织**,任何 env 组合都不行 ——
+  `OS_TENANCY_POSTURE=isolated`、`OS_MULTI_ORG_ENABLED=true`、两个一起设,都不再能把闸门说通。
+  这是一次实打实的能力收缩,不是 knob 纠正,所以搭 v17 主版本车。
+
+  | 部署形状                                          | 改前   | 改后          |
+  | ------------------------------------------------- | ------ | ------------- |
+  | 有企业包,posture `isolated` / `group`(墙真的立着) | 200    | **200**(不变) |
+  | **请求了墙但企业包缺席(D5 降级态)**               | 200    | **403** ⚠️    |
+  | `single` / 两个 knob 都不设                       | 403    | 403(不变)     |
+  | 未注册 `tenancy` 服务的精简嵌入(回落 env 解析)    | 按 env | 按 env(不变)  |
+
+  `serve.ts` 本来就在降级态**默认拒绝启动**(要 `OS_ALLOW_DEGRADED_TENANCY=1` 才走),所以这条收缩
+  命中的是一个已经需要显式选择才能到达的形状:从此那里的 org-create 路由也一并拒绝,而不是半通不通。
+  cloud 控制面与任何装了企业包的部署不受影响。
+
+  **迁移**:需要多组织能力的部署安装并声明 `@objectstack/organizations`(ADR-0081 D2)。仅靠 env
+  声明一个墙、而没有实现它的运行时,不再被当作多组织部署对待。
+
+  ## `@objectstack/verify`(minor,新增)
+
+  `BootOptions.multiTenant` 增加 `'posture-only'` 取值:注册一个内置的 `org-scoping` 服务替身,
+  让 `tenancy` 服务解析出真实、**非降级**的 `isolated` posture,从而打开受 posture 把守的路由 ——
+  供那些「组织墙是**前置条件**而非被测对象」的 fixture 使用(#3624 的 `org-create-default-team`
+  dogfood 就是为它而建:那条回归此前靠「boot 后翻 env、闸门 live 读」开路,本次收缩把这个绕法关死了)。
+
+  ⛔ 它**不做任何租户隔离**:不 stamp `organization_id`,不 scope 任何查询 —— 它让部署的
+  **posture** 为真,不是让**墙**为真。跨租户隔离的唯一诚实证明仍然是 `multiTenant: true` +
+  真实的企业包,这也是那些 gate 在本仓继续 skip 而不是假装通过的原因。
+
+### Minor Changes
+
+- 7cf1531: fix(auth): an unrecognised membership policy is refused by both reconcilers, not auto-bound by one of them (#5205)
+
+  **The sign-up path used to bind anyway.** `reconcileMembership` and
+  `backfillMemberships` — both public exports of `@objectstack/plugin-auth` — read
+  the same `policy` field and judged it with opposite predicates. Sign-up tested
+  `policy === 'invite-only'`, so any _other_ value fell through to the `auto`
+  branch and auto-bound the new user; the backfill tested `policy !== 'auto'` and
+  refused. One input, two opposite postures, and the fail-open half was the one
+  that runs per sign-up. A caller who wrote `'inviteOnly'` — or any host passing
+  the policy from JavaScript, past the `MembershipPolicy` type — got auto-binding
+  while believing they had switched it off, with nothing in the logs to say so.
+
+  Both entry points now check `isMembershipPolicy()` before any policy semantics
+  and refuse: nothing is bound, and the refusal names the offending value at
+  `error` level (and on the returned result, so it survives a caller that passed
+  no logger). This is the posture #5152 took one layer up at the settings
+  boundary — an unrecognised value is rejected loudly, never coerced to `auto`.
+
+  **Contract change — `ReconcileOutcome` gains `'invalid-policy'`, and
+  `BackfillMembershipsResult.reason` gains the same member.** Both are exported
+  types, so a consumer that switches exhaustively over them (a `never`-checked
+  `default`, or a `Record< ReconcileOutcome, … >`) must handle the new member.
+  The new verdict is deliberately _not_ a reuse of the existing `policy-skip` /
+  `'policy'`: those mean "a valid policy said no", and reporting them for "this
+  is not a policy" sends whoever is debugging a missing bind to inspect a
+  deployment setting that is fine. `BackfillMembershipsResult` also gains an
+  optional `error?: string`, and the `logger` shape on `ReconcileMembershipDeps`
+  gains an optional `error?` method (it falls back to `warn`).
+
+  **No behaviour change for the two real policies.** `auto` binds and
+  `invite-only` skips exactly as before, on both paths — the framework's own
+  callers resolve the policy through `AuthManager.getMembershipPolicy()`, whose
+  return type is `MembershipPolicy`, so nothing on a supported path can reach the
+  new branch. This closes the dormant divergence on the export surface.
+
+- 586d6f7: feat(auth): `membership_policy` is a platform setting, and sign-up and backfill read one source (#5152)
+
+  **What a new user joins is now configurable at runtime.** ADR-0093's
+  `membershipPolicy` decides whether a freshly created user is auto-bound to the
+  deployment's default organization (`auto`) or gets membership only from an
+  explicit act — creating a workspace, accepting an invitation, an admin adding
+  them, SSO just-in-time provisioning (`invite-only`). Until now it was settable
+  **only** as an `AuthPlugin` constructor option, and the AuthPlugin a self-hosted
+  stack gets is injected by the CLI, which passes no such option and has no env
+  fallback. Every self-hosted deployment therefore ran `auto`, with no way to say
+  otherwise. `invite-only` was, in practice, unreachable outside a custom host.
+
+  It is now `auth.membership_policy` in the platform settings — a two-value select
+  (`auto` / `invite-only`, default `auto`) alongside `signup_enabled`, which it
+  pairs with: one says whether people may self-register, the other says what they
+  join when they do. Set it in Setup → Authentication → Membership, or pin it
+  per-deployment with `OS_AUTH_MEMBERSHIP_POLICY`. It applies **without a
+  restart** — the existing `settings.subscribe('auth', …)` re-application seam
+  carries it, the same one the password-policy keys ride.
+
+  **No behaviour changes unless you set it.** Only an _explicit_ value applies;
+  the manifest's `auto` default is a UI default and never masks a deployment that
+  configured the policy in code. A stack that sets nothing keeps today's
+  auto-binding exactly.
+
+  **Bug fix — the two membership paths read one source.** Sign-up (the reconciler
+  in better-auth's `user.create.after`) read the AuthManager's live config, while
+  the ADR-0093 D6 backfill of pre-existing member-less users read the plugin's
+  **constructor options**. Wiring a setting to the first and not the second would
+  have produced "sign-up honours the new policy, backfill still runs the old one"
+  — and the backfill binds in **bulk**, so it is the more dangerous half. Both now
+  resolve the policy through the new `AuthManager.getMembershipPolicy()`, and the
+  backfill waits for the settings namespace to bind before its first pass (the two
+  `kernel:ready` hooks fire in registration order, which was the wrong order).
+
+  **An invalid value is rejected, not coerced.** `PUT /api/settings/auth` refuses
+  a policy outside the declared option table (`invalid_option`, naming the allowed
+  set). A value arriving from `OS_AUTH_MEMBERSHIP_POLICY` — which bypasses that
+  validation — is logged at `error` and **ignored**, leaving the deployment's
+  current policy in force; it is never silently read as `auto`, because that would
+  leave an operator believing a wall is up while every sign-up is auto-bound.
+
+  New public API on `@objectstack/plugin-auth`: `AuthManager.getMembershipPolicy()`,
+  plus `MEMBERSHIP_POLICIES` and `isMembershipPolicy()` from `reconcile-membership`.
+
+- 61dc08e: feat(plugin-auth): break-glass — a ban may never leave the environment with zero administrators (#5892)
+
+  `sys_user.banned = true` is where every deprovision lands: better-auth's admin
+  plugin writes it, and `@better-auth/scim` maps a SCIM `active: false` onto that
+  same admin ban. Nothing checked what the write left behind — so **banning the
+  last administrator was allowed, reported success, and locked the organization
+  out of its own environment permanently.** SCIM makes that a realistic accident
+  rather than a hypothetical one: the write is driven by an external system, so
+  nobody reads the payload before it commits, and one mis-scoped IdP group is
+  enough.
+
+  **New guard (`last-admin-ban-guard.ts`, cloud ADR-0024 D5.2).** A `beforeUpdate`
+  hook on `sys_user` refuses any write that turns `banned` on when it would leave
+  the environment with **no unbanned administrator**. It sits on the write, not on
+  an endpoint, so it holds for the admin ban endpoint, the SCIM adapter write, an
+  import, a script, and anything added later — by-id **and** predicate/`multi`
+  writes alike.
+
+  Who counts as an administrator is exactly what the rest of the platform already
+  counts: a platform admin (an unscoped, in-window `admin_full_access` grant —
+  the same evidence `resolveAuthzContext` derives `platform_admin` from) or an
+  organization `owner`/`admin` membership. `delegated_admin` does not count
+  (ADR-0105 D8: it can reach an endpoint, it carries no authority), an expired
+  grant does not count, and the non-loginable `usr_system` account does not count.
+
+  Three consequences worth knowing before you upgrade:
+
+  - The refusal is a **403** carrying `PERMISSION_DENIED` and a message that names
+    the user, the invariant, and the fix (grant someone else `admin_full_access`
+    or an owner/admin membership first — and if an IdP drove the ban, the SCIM
+    deprovision is too broad). On the auth pipeline it now surfaces as a proper
+    `APIError` instead of an opaque 500.
+  - It **fails closed**: if the administrator population cannot be read, or is too
+    large to enumerate, the ban is refused rather than guessed at. The failure
+    mode being prevented is a permanent lockout.
+  - Writes that do not turn `banned` on — unbans, profile edits, re-banning an
+    already-banned admin — are untouched, and so is banning anyone who is not an
+    administrator.
+
+  The other half of the same invariant (`enforced` SSO must never disable the last
+  local admin's **password** — the escape hatch for an IdP outage) was already
+  implemented and is now pinned by tests rather than reimplemented:
+  `emailAndPassword.enabled` stays `true` under enforced SSO while sign-up is
+  forced off, and the last local `credential` account still cannot be banned,
+  removed or deleted.
+
+- 8dcf607: feat(plugin-auth): break-glass — the last administrator cannot be DELETED either (#5941)
+
+  #5892 closed the _ban_ half of ADR-0024 D5.2's break-glass invariant. The
+  **delete** half was still open, and it was reachable end to end: in an enforced
+  SSO environment the last administrator is typically IdP-managed and holds no
+  local password, so when the IdP drops them from the admin group the resulting
+  SCIM `DELETE /Users/{id}` (or `/admin/remove-user`, or `/delete-user`) removed
+  the row and **left the environment with nobody able to administer it** — quite
+  possibly with a password-holding non-admin still able to sign in and change
+  nothing. There is no recovery path from inside the product once that happens.
+
+  The pre-existing HTTP guard on those three endpoints did not cover it: it
+  protects the last holder of a local `credential` account, so it skips the
+  credential-less (IdP-managed) target entirely. It is unchanged and keeps
+  enforcing its own invariant.
+
+  **What changed.** The guard module now enforces one invariant on _both_ writes
+  that can take the last administrator away, off one administrator enumeration:
+
+  | write                       | hook                     |
+  | :-------------------------- | :----------------------- |
+  | `sys_user.banned = true`    | `beforeUpdate` (#5892)   |
+  | deleting the `sys_user` row | `beforeDelete` (**new**) |
+
+  The delete half is the ban half's twin in every property that matters: it sits
+  on the **write**, so it holds for the SCIM adapter delete, better-auth's admin
+  remove-user, an import and a script alike; it covers by-id **and**
+  predicate/`multi` deletes (including the unpredicated `multi` that would empty
+  the table); it applies to **every** context, `isSystem` included, because the
+  deprovision path that actually locks organizations out is the system one; and it
+  **fails closed** — an administrator population that cannot be read, or is too
+  large to enumerate, refuses the delete rather than guessing.
+
+  The refusal is a **403** carrying `PERMISSION_DENIED` and names the operation
+  the caller actually attempted ("Refusing to delete 'usr\_…'"), the invariant
+  (ADR-0024 D5.2), and the fix — grant someone else `admin_full_access` or an
+  owner/admin membership first, and if an IdP drove it, the SCIM deprovision is
+  too broad. On the auth pipeline it surfaces as an `APIError`, not an opaque 500.
+
+  Untouched: deleting anyone who is not an administrator, deleting an
+  administrator while another unbanned one remains, and deleting an administrator
+  who is already banned (that account could not sign in either way).
+
+  **Rename.** The module is now `last-admin-guard.ts` and the exported registration
+  function is `registerLastAdminGuard` (was `last-admin-ban-guard.ts` /
+  `registerLastAdminBanGuard`, added in the same unreleased cycle) — it registers
+  both hooks, so the old name would have understated what it installs. Hosts that
+  wire the guard onto their own ObjectQL engine rename the import; there is no
+  other change to its signature or behaviour.
+
+  Not covered, tracked separately (#5978): revoking the _standing_ that makes
+  someone an administrator — deleting or downgrading their `sys_member` row,
+  removing the `admin_full_access` grant — leaves the user row in place and writes
+  a different table, so neither hook sees it.
+
+### Patch Changes
+
+- 7a40b7a: fix(plugin-auth): better-auth 的 `contains` 下译为 `$contains`,比较值不再当正则求值 (#5710)
+
+  `convertWhere()` 把 better-auth 的 `contains` 译成 `{ field: { $regex: value } }`,
+  于是一个**未转义、来自调用方**的比较值(`/admin/list-users` 的 `searchValue`、
+  SCIM 过滤值)坐进了正则的**模式位**。它的含义随后端分叉:
+
+  - `driver-memory` 用 `new RegExp(value)` 求值 —— `contains('a.b')` 命中 `axb`,
+    `^x` 变成锚定,而值里一个不配对的 `(` 让模式非法(mingo 查询路径直接抛
+    `SyntaxError`,参考匹配器则吞成静默零命中);
+  - `driver-sql` / `driver-sqlite-wasm` / `driver-turso` 编成子串
+    `LIKE '%value%'`(`%`/`_`/`\` 有转义、带显式 `ESCAPE`),元字符是字面量。
+
+  同一个认证查询,在应用测试常用的内存替身上和生产的 SQL 后端上给出**不同答案**,
+  且分叉发生在认证路径上。
+
+  现在这一支发出 `$contains` —— 协议 `FILTER_OPERATORS` 里的算子,五后端都必须按
+  **字面子串**求值,正是 better-auth `contains` 的本意(其 `Where.mode` 默认
+  `"sensitive"`,与 #5701 Q2=A 裁定的 `$contains` 大小写敏感契约同向)。
+
+  **对使用方的影响**:凭 `/admin/list-users?searchValue=…` 之类接口依赖「元字符按正则
+  生效」的调用会改变结果 —— 那是本次修复的缺陷本身,不是可依赖的行为。搜索
+  `a.b` 从此只命中含字面 `a.b` 的行,不再命中 `axb`;含非法正则字符的搜索值不再
+  报错或静默返回空,而是按字面子串匹配。
+
+- 2d14b35: fix(plugin-auth): `convertWhere()` 补齐 `not_in` / `starts_with` / `ends_with`,未识别算子改为响亮拒收 (#5813)
+
+  `convertWhere()` 的分支链只覆盖 better-auth 十一个算子里的八个。
+  `not_in` / `starts_with` / `ends_with` 落在链尾之外:**`filter` 里不写任何键**,
+  不告警,链尾也没有 `else` 兜底。一个只带这类条件的 `where` 因此编成 `{}`。
+
+  **丢谓词不是把结果变窄,是变宽 —— 而且发生在身份表上**(#3948 反复论证过的形状,
+  driver-memory 的匹配器 `default:` 臂与 objectql 的 `having` 都为此改成了拒收):
+
+  - `findMany` / `count` 变成**全表**(仅受 `limit` 截断)。已挂载的
+    `GET /api/v1/auth/admin/list-users`(`auth-route-ledger.ts:161`)把查询参数直接
+    推进 `where`,而 `searchOperator` 的枚举是 `contains | starts_with | ends_with`、
+    `filterOperator` 的枚举**就是整张算子表**。于是
+    `?searchValue=abc&searchOperator=starts_with` 返回的是「全部用户」而不是「以 abc
+    开头的用户」,`?filterField=email&filterOperator=not_in&filterValue=…` 不排除任何人。
+    管理台的用户检索是它的主要消费者。
+  - `update` / `delete` / `consumeOne` / `incrementOne` 走的是「先 `findOne(filter)`
+    再按 id 写」,`{}` 让 `findOne` 返回**任意一行**(实测是第一行),于是写到了错误的
+    记录上。实测证据:对四行表执行「删除 `name` 以 `zed` 开头的用户」,修复前删掉的是
+    `u_abc1`(第一行),不是 `u_zed`。
+
+  ## 改了什么
+
+  **一、三个算子按词表直译**(三个 ObjectQL 算子都在 `FILTER_OPERATORS` 里,
+  五后端都必须求值):
+
+  | better-auth   | ObjectQL      |
+  | :------------ | :------------ |
+  | `not_in`      | `$nin`        |
+  | `starts_with` | `$startsWith` |
+  | `ends_with`   | `$endsWith`   |
+
+  大小写语义两侧同向,直译不开契约缝:better-auth 的 `Where.mode` 默认
+  `"sensitive"`,`$startsWith` / `$endsWith` 按 #5701 Q2=A 在契约层也是大小写敏感。
+
+  **二、链尾未识别算子响亮抛错**,不再静默丢。错误信息带算子名、字段名与受支持算子
+  清单,本身就是操作指引。这是 restore-invariant:否则 better-auth 下次加算子时,
+  这个洞会以完全相同的方式重开一次。
+
+  ## 对使用方的影响
+
+  - 用上述三个算子的查询**从「返回全表 / 写错行」变成「按谓词正确过滤」**。这是缺陷
+    修复,不是可依赖行为的移除 —— 但依赖「`starts_with` 检索能列出全部用户」的脚本会
+    看到结果变化。
+  - 传入**词表之外**的算子从「静默忽略该条件」变成**抛错**。今天没有活体调用方能命中
+    这一支(`/admin/list-users` 的两个参数都由 better-auth 自己的 zod 枚举把关),它面向
+    的是将来:better-auth 长出第十二个算子时,查询会在第一次执行就失败,而不是悄悄放大。
+    该分支同时是编译期哨兵(`never` 收敛),`pnpm --filter @objectstack/plugin-auth
+typecheck` 会先一步报错。
+  - `Where.mode: 'insensitive'` **不在**本次范围内,也不会被这条拒收波及 —— `mode` 是
+    `operator` 的兄弟字段而非算子,今天仍被忽略(#5814,决策箱中)。
+
+- 93929c2: fix(plugin-auth): break-glass 不变量补上第三条路径 —— 撤销「管理员身份」的写(`sys_member` 降级/删行、`admin_full_access` 授权删/改)同样被拒 (#5978)
+
+  cloud ADR-0024 D5.2 的不变量是「环境永远至少留一个能登录的管理员」。此前它由两个引擎钩子守着,
+  **都装在 `sys_user` 上**:`banned = true`(#5892 / PR #5939)与删 `sys_user` 行(#5941 / PR #5993)。
+
+  但「谁是管理员」这件事根本不存在 `sys_user` 上 —— 它由另外两张表推导(`resolveAdminUserIds`
+  正是从这两张表反向枚举的)。于是第三条写法完全绕开两个守卫:**用户行原封不动,把他的管理员身份拿掉**。
+
+  - 把最后一个管理员的 `sys_member.role` 降到 admin 等级之下(better-auth 的 `updateMemberRole`、
+    一次 SCIM 组映射变更、导入、脚本),或直接删掉那条 `sys_member` 行;
+  - 删掉那条 `admin_full_access` 的 `sys_user_permission_set` 授权,或把它改到不再生效
+    —— 改指向别的权限集、加上 `organization_id` 组织作用域、把 ADR-0091 有效期窗口改过去。
+
+  三者事后状态与「删掉最后一个管理员」完全等价:所有人都还在,没有任何人能管理任何东西,
+  产品内部无恢复路径。
+
+  **新增的拒写语义。** 守卫现在按同一形状扩到 `sys_member` 与 `sys_user_permission_set` 的
+  `beforeUpdate` / `beforeDelete`(共六个钩子,同 `packageId`、同 priority 20)。判据就是 issue 的原话
+  ——**枚举、模拟、再枚举**:先枚举当前管理员,再把这次写落地后的行拿同一个枚举函数跑一遍,
+  若第二次为空而第一次不为空则拒写。两次枚举是同一份实现,「谁是管理员」不可能对写前问题和写后问题
+  给出两个答案。
+
+  - **全覆盖,不是只拦自降级**:真正会发生的是 IdP 组映射改别人的角色,不是管理员给自己降级。
+  - **谓词/批量写照判**:一次 `where` 命中多行的 update/delete 会先解析出整个匹配行集再做写后模拟,
+    而不是一律拒绝;只有匹配集本身解析不出来(读失败,或超过 `maxScan`)才响亮拒写。
+  - **fail-closed**:枚举失败或形状不确定一律拒写并点名 ADR-0024 D5.2,与既有两半同向。
+  - 模拟是**单向**的 —— 只会拿走身份,不会授予身份(把 role 从 `member` 升到 `admin`、把授权改指向
+    `admin_full_access` 这类写,模拟看不见新增的管理员),因此每一处取整都倒向「拒写」而非「放行」。
+
+  **不拦的**:降级到**另一个** admin 等级(`owner` → `admin`,或逗号拼写 `member,admin`)—— 等级未失;
+  已被 ban 的管理员的身份被撤(本来就不能登录,没有东西被拿走);非管理员的 membership/授权;
+  以及不触及 `role` / `user_id`(membership)或权限集/作用域/有效期(授权)的 payload —— 这类写
+  静态可证不改变枚举结果,一次读都不做。
+
+  有效期语义按 `resolveAdminUserIds` 现有的 `isGrantActive`(ADR-0091 D2)**原样消费**,本次不新造
+  (#5893 才是那个问题的归属单)。等级判定全程只问 `isOrgAdminGrade` 这把唯一的尺(#5939 / #5942),
+  守卫内没有任何手抄的 role 解析。
+
+- 08f93bc: fix(auth): `organization/create` gates on the authoritative `OS_TENANCY_POSTURE`, not the demoted `OS_MULTI_ORG_ENABLED` (#5233)
+
+  A deployment configured the documented way — `OS_TENANCY_POSTURE=isolated` (or
+  `group`), legacy boolean unset — mounted the entire organization wall and still
+  answered `403 Creating additional organizations is disabled on this deployment.`
+  to `POST /api/v1/auth/organization/create`. Org-less users had no way to create
+  their workspace, so the guided "Create your workspace" path was a dead end.
+
+  ADR-0105 D1 made `OS_TENANCY_POSTURE` the canonical knob and demoted
+  `OS_MULTI_ORG_ENABLED` to a back-compat _input_ of `resolveTenancyPosture()`.
+  Two sites in `AuthManager` kept reading the demoted boolean directly, so both
+  reported "single-org" on a deployment that had asked for a wall and got one:
+
+  - `organizationHooks.beforeCreateOrganization` — the 403 above. It now judges
+    `postureEnforcesWall(resolveTenancyPosture())`, matching the knob `serve.ts`'s
+    own ADR-0093 D5 boot guard keys on. Intent is unchanged (single-org still
+    refuses); only the knob is corrected.
+  - `/auth/config`'s `features.multiOrgEnabled` — its no-tenancy-service fallback
+    read the same boolean. It now falls back to the resolved posture, so a lean
+    embedding advertises the capability its own gate allows.
+
+  **No configuration change is needed anywhere.** Deployments that set only
+  `OS_MULTI_ORG_ENABLED=true` keep working unchanged — `resolveTenancyPosture()`
+  falls back to it — and the `OS_TENANCY_POSTURE=isolated` + `OS_MULTI_ORG_ENABLED=true`
+  workaround people used to unblock themselves stays valid. Deployments that set
+  only `OS_TENANCY_POSTURE` can now drop the redundant boolean.
+
+  `resolveMultiOrgEnabled()`'s doc comment in `@objectstack/types` — which still
+  instructed "the auth manager's `/auth/config` feature flag and org-create guard
+  … MUST call this", written before the demotion — now says the opposite: ask the
+  posture, and never gate on this boolean. Its behaviour is unchanged.
+
+- 55dbbba: feat(spec,runtime,hono): `server.security.rateLimit` — an authored budget that actually returns 429 (#4910, #4937)
+
+  Rate limiting in ObjectStack was three shapes with nothing between them. `packages/spec`
+  declared `RateLimitConfig` in three places and the whole repo had **zero readers** for any
+  of them, so an author wrote a budget, it parsed, and nothing happened (#4686).
+  `@objectstack/runtime` shipped a token bucket whose comments claimed, in the present tense,
+  that the dispatcher called it and short-circuited with 429 — it had **zero call sites**
+  outside its own unit test, and the `DispatcherPluginConfig.rateLimit` field it told you to
+  tune did not exist (#4937). Neither half was broken; they were simply never connected, and
+  both were documented as if they were.
+
+  They are connected now, along one narrow path.
+
+  ## What you write
+
+  ```ts
+  export default defineStack({
+    manifest: {
+      /* … */
+    },
+    server: {
+      security: {
+        rateLimit: { enabled: true, windowMs: 60_000, maxRequests: 600 },
+      },
+      trustProxy: false,
+    },
+  });
+  ```
+
+  `server:` is a **new** top-level stack key. Nothing declared it before, so no existing
+  stack changes behaviour on upgrade — there is no configuration that was inert yesterday
+  and starts throttling today.
+
+  It is deliberately **narrow**: it carries `security.rateLimit` and `trustProxy` and
+  nothing else, because those are the two keys with a consumer. It is NOT the nine-key
+  `HttpServerConfigSchema` — the other seven have no reader and no authoring surface, and
+  mounting them here would have made seven dead keys writable in one move (their
+  enforce-or-remove fate stays with #4938). It is strict from birth (#4001), so a misspelled
+  budget is rejected with the correction rather than silently defaulted, and `maxRequests: 0`
+  is refused at `defineStack` rather than at 3am.
+
+  **No `server.port`.** The listening socket belongs to the deployment, not the artifact, and
+  `objectstack serve -p` already owns it. The precedence rule is recorded in the schema and
+  the docs in advance, so it cannot be re-litigated per caller: **CLI flag > `server:` >
+  built-in default.**
+
+  ## What happens
+
+  Every inbound request the server routes — REST, dispatcher, service routes, anything
+  mounted on that transport — consumes from a token bucket sized `capacity = maxRequests`,
+  refilling at `maxRequests / (windowMs / 1000)` per second. An empty bucket answers **429**
+  with a `Retry-After` computed from the bucket itself and the standard error envelope
+  (`code: "RATE_LIMIT_EXCEEDED"`). `OPTIONS` preflights are never metered.
+
+  The bucket is keyed by **resolved principal**, falling back to the caller's **IP** for
+  anonymous traffic — so one abusive session cannot spend another user's budget, and
+  credential-stuffing traffic (which has no principal yet) is still metered per source. That
+  IP comes from `X-Forwarded-For` / `X-Real-IP` **only when `trustProxy: true` is declared**;
+  otherwise it is the transport's own peer address. Undeclared, those headers are attacker
+  input: honouring them by default would hand anyone an unlimited supply of fresh buckets and
+  let them drain a chosen victim's.
+
+  Counters live in the kernel `cache` service when one is registered, so a multi-node
+  deployment enforces one budget instead of one per node (ADR-0069 D2), resolved lazily at
+  consume time so a cache plugin that registers later is still picked up (#4772). With no
+  cache service at all it falls back to a per-process store and says so once, naming the
+  consequence: the effective limit becomes the declared budget multiplied by the number of
+  nodes, and nothing about the deployment looks wrong.
+
+  ## Also in this change
+
+  - **`IHttpServer.use()` is a real middleware seam.** The Hono adapter's implementation
+    passed `{}` for both `req` and `res` and called `next()` unconditionally, so a registered
+    middleware could not read the request, write a response, or decline to continue — a
+    declared seam with no execution behind it, unnoticed because nothing called it. It now
+    delivers method/path/query/headers plus the transport peer address
+    (`IHttpRequest.remoteAddress`, new), and honours a short-circuit. Middleware must be
+    registered before the routes it guards; the kernel's two-phase boot makes that automatic
+    (`init()` before every `start()`).
+  - **`packages/runtime/src/security/rate-limit.ts` no longer describes an execution chain it
+    does not have** (#4937). The token-bucket arithmetic is extracted so the synchronous
+    in-process limiter and the new shared-store one cannot drift, and `DEFAULT_RATE_LIMITS` is
+    now labelled as the reference material it always was rather than as live defaults.
+
+  ## Explicitly NOT wired
+
+  `ApiEndpointSchema.rateLimit` and `ApiEndpointRegistrationSchema.rateLimit` remain
+  **known-unwired**. Declaring them still changes nothing. They are not retired here either:
+  the fate of the whole declarative `apis:` surface is undecided (#4936), and retiring one
+  key of a surface that may yet be implemented would only have to be undone. Tracked, not
+  silent.
+
+- 9fa6bab: fix(plugin-auth): sign JWTs with an algorithm the host can actually use (#3585)
+
+  On any host whose WebCrypto lacks Ed25519 — StackBlitz/WebContainer is the
+  reported one — **every authenticated request 500'd as soon as the OIDC provider
+  was enabled**, which is the default whenever the MCP server is on. Sign-in
+  succeeded, then the first `/api/v1/auth/get-session` returned 500 with
+  `OperationError … cfrgGenerateKey`. An app that never asked for OIDC got an
+  unusable login, and the only escape was `OS_OIDC_PROVIDER_ENABLED=false`.
+
+  The cause was an inherited default: `plugin-auth` registered better-auth's `jwt`
+  plugin without `jwks.keyPairConfig`, so better-auth's **EdDSA / Ed25519** default
+  applied and jose asked WebCrypto for an algorithm the host does not have. It hit
+  ordinary cookie login rather than just OAuth clients because the plugin's `after`
+  hook signs a `set-auth-jwt` header for _every_ session.
+
+  **Three changes, no configuration required:**
+
+  - **The signing algorithm is now chosen by capability, not by inheritance.** At
+    instance build the plugin asks WebCrypto whether it can generate an Ed25519
+    key pair — using the exact algorithm descriptor jose uses — and pins
+    `keyPairConfig` to `EdDSA`/`Ed25519` when it can, or falls back to **ES256**
+    when it cannot. Hosts with Ed25519 behave exactly as before.
+  - **Deployments that already minted an EdDSA key keep working.** Choosing ES256
+    for _new_ keys is not sufficient on its own: better-auth's `resolveSigningKey`
+    falls back to _any_ stored key when none matches the configured algorithm, so
+    an existing EdDSA key in `sys_jwks` would still be selected and then fail in
+    `importJWK`. On a host without Ed25519 the plugin now installs better-auth's
+    `adapter.getJwks` keyring seam and hides keys this host cannot import, so a
+    fresh ES256 key is minted and the deployment converges on a working state.
+    Hidden rows are **never deleted** — move back to a host with Ed25519 and they
+    are used again. Such a host also stops advertising those keys in
+    `/api/v1/auth/jwks`, since it can neither sign nor verify with them.
+  - **A signing failure can no longer take down the session path.** If signing
+    fails anyway (neither algorithm usable, an unwritable `sys_jwks`, or a rotated
+    `OS_AUTH_SECRET` that cannot decrypt the stored key), `/get-session` now
+    returns the session normally and simply omits the `set-auth-jwt` header,
+    instead of 500ing. The failure is reported once with an error that names the
+    algorithm, says what still works, and points at the opt-out — and is queryable
+    via `getDegradedAuthFeatures()` under the new `jwtSigning` key.
+
+  No configuration changes and no migration. Deployments on hosts with Ed25519 are
+  unaffected: the keyring override is installed only where it is needed.
+
+- b691ba9: fix(plugin-auth): break-glass 守卫扩到 `sys_permission_set`,并把「零管理员」从引导期豁免里分辨出来 (#6084)
+
+  break-glass 不变量(cloud ADR-0024 D5.2)此前守三张表:`sys_user`(ban/删行,#5892/#5941)与
+  `sys_member`/`sys_user_permission_set`(撤销 standing,#5978)。**第四条写法绕开全部三条**:
+  「谁是 platform admin」是**按名字**解析的——`resolveAdminUserIds` 先
+  `where: { name: 'admin_full_access' }` 取那条 `sys_permission_set` 行,再去读指向它 id 的授权行。
+  删掉那一行、或把它改个名字,授权行、`sys_user` 行、`sys_member` 行**一个都没动**,而所有
+  platform admin 同时不再是管理员。
+
+  ## 放大缺陷:这一条写法还会顺手关掉守卫本身
+
+  两个判据都以「这个环境有管理员吗?没有就放行」开场——引导期本就没有 break-glass 账号可保护,
+  在那个窗口里拒绝一切身份写会是守卫拿一个空测量值自造政策。可是 `admin_full_access` 行没了的环境
+  **读起来正是零管理员**,于是豁免生效,ban / 删用户 / 降级 / 撤授权**一并放行**。所以这一条写法
+  不只是锁死环境,还在锁死的路上把 #5892 / #5941 / #5978 三条守卫一起解除。
+
+  ## 两处改动
+
+  **① 同形状扩到第四张表。** `sys_permission_set` 的 `beforeUpdate` + `beforeDelete`,复用 #5978 的
+  `enforceStanding` / `applyPending`,`PendingStandingWrite` 多认一张表;枚举的第一段 scan 现在也对
+  pending 做模拟并**重测 `name`**——与 grant 半边重测 `permission_set_id` 同理,scan 自己的 `where`
+  只证明了写**之前**那行叫什么。静态跳过键只有 `name` 一个:枚举只读这一列,所以每一次 projection
+  回填、每一次 `os meta resync`、每一次 Setup 里编辑权限集(写的是 `label`/`description`/权限 JSON)
+  一次读都不花。数据门自己已经拒绝改名(ADR-0094),这道守卫覆盖的是不经数据门的引擎级与
+  system-context 写。
+
+  **② 收紧引导期豁免。** 「零管理员」拆成它本来混在一起的两种状态:
+
+  - **真引导期**——没有任何证据说这里曾经有过 platform admin。照旧放行。
+  - **刚被清空**——仍存在无组织范围、有效期内的 `sys_user_permission_set` 授权行,而它指向的
+    `sys_permission_set` 行已经不在了。fail-closed 拒写,并在报文里点名那些悬空授权行。
+
+  判据选的是**悬空授权行**,因为它在正常路径上根本写不出来:每一个生产者都先插权限集、再读回 id 写
+  授权行(`bootstrapPlatformAdmin` 第 1 步 seed 权限集、第 2 步才提拔第一个用户,权限集缺席时返回
+  `admin_permission_set_missing` 而不是发授权),所以**全新环境的可写性按构造不变**——测试里有一条
+  「真引导期照常放行」的钉专门量这一点。改名不留下悬空授权行,这条判据看不见它;那条路径改由 ① 在
+  写入处拦下,残留因此只剩一种状态:守卫尚未注册时落下的改名。曾考虑把判据放宽成「不存在
+  `admin_full_access` 行 且 存在无组织范围授权行」,被否掉——它会改变「seed 顺序先写授权行」的全新
+  环境的答案,而不改变全新环境的答案正是这条判据唯一不能碰的红线。
+
+  `sys_permission_set` 的拒绝报文结尾不走 SCIM 那句:IdP 不写这张表,写它的是元数据删除、
+  `os meta` 与包卸载,报文点名的是这些门。
+
+- 4addd9d: feat(driver-sql)!: organization-scoped uniques are NULL-safe — `COALESCE(organization_id, '__global__')` key part + `unique: 'organization'` on declared indexes (ADR-0120 D3/D4, #5030)
+
+  SQL UNIQUE is NULL-distinct, so the `(organization_id, field)` composite #3696
+  introduced enforced **nothing** on rows whose organization is NULL — which on a
+  single-tenant stack (where the kernel injects the column and never fills it) is
+  **every row**: field-level `unique: true` was a silent no-op there, measured in
+  #5030. Per ADR-0120 D3, every organization-scoped unique now materializes its
+  organization key part as `COALESCE(organization_id, '__global__')`: NULL-organization
+  rows collapse into one platform bucket, unique among themselves; non-NULL rows
+  are untouched. Storage stays NULL — the sentinel exists only inside the index
+  key, and it is the same word the autonumber sequence table already uses
+  (`GLOBAL_TENANT`), so a constraint-violation error reads as "the platform
+  bucket collided", not as corrupt data.
+
+  What changes, concretely:
+
+  - **Field-level `unique: true`** (and the new explicit synonym
+    `'organization'`) on a tenant-scoped object → composite
+    `(COALESCE(tenantField, '__global__'), field)`. `unique: 'global'` and
+    tenant-less objects are unchanged.
+  - **Declared indexes gain the ADR-0120 D1 scope vocabulary at the driver**:
+    `unique: 'organization'` prepends the NULL-safe organization key part to the
+    listed columns (degrading to the listed columns on a tenant-less object; a
+    listed tenant column is made NULL-safe in place instead — the S6 respelling).
+    `unique: true` / `'global'` on a declared index stays **verbatim** — the
+    #3696 contract, now the `'global'` arm; the nine engine dedup/idempotency
+    keys keep their exact physical shape. (The spec/lint side of the vocabulary
+    lands separately via #4986; the driver deliberately merges first.)
+  - **Drift detection reads both sides through one normalization**
+    (the #4884 discipline, extended to the tenant key part): the physical
+    `COALESCE(organization_id, <literal>)` form is attributed to the column,
+    compared **literal-agnostically**, and recognised as the sync's own
+    vocabulary — a healthy database reports zero drift on every dialect.
+  - **Existing bare composites migrate through the ceremony (ADR-0120 D4)**:
+    `(organization_id, X) → (COALESCE(organization_id, '__global__'), X)`
+    surfaces as a `recreate_index` drift op — a pure tightening — gated by a
+    **duplicate pre-flight probe**. Clean probe → the op grades `safe` and dev
+    `autoMigrate: 'safe'` / a plain `os migrate apply` applies it. Duplicates
+    (data the void constraint wrongly admitted) → the op is **blocked** with a
+    per-group row report, the old index stays in place, and apply re-probes so
+    even `--allow-destructive` cannot drop a constraint whose replacement is not
+    creatable. Deduplicate, re-plan, apply.
+  - **`'__global__'` is reserved at the organization-minting seam**
+    (plugin-auth): an organization whose id or slug equals the sentinel is
+    rejected at creation with a prescriptive error (ADR-0120 D3 guardrail).
+
+  Migration note for operators: on databases with pre-existing
+  organization-composite uniques, the first `os migrate plan` after upgrading
+  shows one `recreate_index` per affected index. On healthy data it auto-applies
+  in dev and is a no-op content-wise; a blocked op means the #5030 defect
+  admitted real duplicate rows — resolve the listed rows first. MySQL < 8.0.13 /
+  MariaDB cannot express the functional key part: the driver degrades to the
+  bare composite, says exactly what is not enforced at `error` level, and keeps
+  reporting the tightening as drift for after the server upgrade.
+
+- db8c285: fix(plugin-auth): 短信日配额拒发时,OTP / 邀请短信按 429 TOO_MANY_REQUESTS 作答,不再是 500 (#6039)
+
+  #2814 把短信总量成本闸落在 `SmsService.send()` —— 它是内核服务,不知道调用方是谁,
+  所以超限时**返回**一条失败结果,把码写在服务层既有的 `CODE: message` 信封上:
+  `TOO_MANY_REQUESTS: daily SMS quota exhausted`。把 HTTP 语义还原回去是 auth 端点的
+  职责,而 `AuthManager` 此前没有做:`deliverPhoneOtp()` / `sendPhoneInviteSms()` 对
+  任何 `status === 'failed'` 一律抛普通 `Error`。
+
+  better-auth 的路由层 better-call 只把 `APIError` 映射成真实状态码
+  (`isAPIError = err instanceof APIError || err?.name === 'APIError'`,
+  better-call@1.3.7 `dist/utils.mjs:57`,消费点在 `dist/router.mjs:93`),其余一律走
+  `console.error` + **500、响应体 `null`** 的分支。于是配额拒发对外是 500,
+  `TOO_MANY_REQUESTS` 只留在服务端日志里;而**同一个端点**上按号码冷却闸
+  (`assertPhoneOtpSendAllowed`,在 admission hook 里)抛的是
+  `APIError('TOO_MANY_REQUESTS')`,正常回 429 —— 一个端点两种口径,正是 #2814
+  「两道墙从外面看应当一样」的反面。
+
+  现在两处失败分支都先识别信封上的 `TOO_MANY_REQUESTS:` **前缀**,改抛
+  `APIError('TOO_MANY_REQUESTS')`:
+
+  - **只有码跨包**。识别用的 `TOO_MANY_REQUESTS` 在 plugin-auth 本地写死并注明出处
+    (`SMS_QUOTA_EXCEEDED_CODE`,`packages/services/service-sms/src/sms-daily-quota.ts`)——
+    `@objectstack/service-sms` 已经依赖本包(它的日计数器从这里 import
+    `InProcessCounterStore`),反向 import 会成环;这与 service-sms 里
+    `normalizeSmsRecipient` 就地重述 plugin-auth 形状规则是同一个取舍的另一半。
+    跨包重述的只是一个 ADR-0112 闭集错误码,冒号后的措辞归服务层所有,可以自由改写。
+  - **不泄露预算**。429 文案沿按号码闸的措辞形状,不含上限、剩余量与重置时刻
+    (按号码闸报自己的重试窗口,是因为它算得出;配额闸不承诺它给不出的时间)。
+  - **不顺手收紧**。传输故障(provider 宕机等)仍抛普通 `Error`,500 语义原样不变;
+    仅仅在文中提到该码而不以之开头的 provider 报错同样保持 500。
+
+  对外可见的变化:`POST /phone-number/send-otp`、
+  `POST /phone-number/request-password-reset` 在部署日配额耗尽时,由
+  **500 + 空响应体**变为 **429 TOO_MANY_REQUESTS**,与按号码冷却闸同形。
+  邀请短信路径同样返回 `APIError`;仓内唯一调用方(admin import-users)按行捕获它并
+  记为 `INVITE_SMS_FAILED`,该路径的变化是行内报错不再携带服务层原始信封。
+
+- b40f81c: docs(plugin-auth): the session of record is always `sys_session` — cache backs rate-limit counters only (#4785)
+
+  Settles an architectural question that had been answered two different ways by
+  the code and the docs. **Nothing about the runtime changes**: this records the
+  decision, proves the behaviour that depends on it, and corrects the docs that
+  described the road not taken.
+
+  **The decision.** ObjectStack's session of record is always the `sys_session`
+  table. The kernel `cache` service serves authentication as the ADR-0069 D2
+  rate-limit counter store and nothing else. It is never bound as better-auth's
+  `secondaryStorage`, because that option is not a counter store — handing
+  better-auth one also relocates sessions into it (`createSession` skips the
+  `sys_session` row; `findSession` answers from the cached snapshot without
+  reading the database). ADR-0069 D4's three session controls — idle timeout,
+  absolute lifetime, concurrent-session cap — all revoke by writing that row, so a
+  cache-backed session store would silently disable every one of them. Dual-writing
+  (`session.storeSessionInDatabase: true`) was considered and rejected as the worst
+  of the options: the row exists, so the controls _appear_ to work, while the read
+  path still answers from the cache.
+
+  **Why this needed settling rather than just fixing.** The conflict had never
+  fired — the cache lookup that would have wired `secondaryStorage` ran before the
+  cache service registered, so the binding never took in a standard composition.
+  The declaration and the runtime disagreed for a month and no test could tell,
+  because no test asserted that a D4 control ends a _live session_; they asserted
+  at most that a row got stamped. A stamped row nobody reads is exactly the failure
+  mode in question.
+
+  **What is new.** `session-of-record.test.ts` drives the real better-auth pipeline
+  end to end and proves each of the three D4 controls actually de-authenticates a
+  live session cookie — not that a column was written. It also pins the
+  counter-factual: with a `secondaryStorage` bound, `sys_session` stays empty and
+  the idle timeout never fires. Two facts that make the guarantee hold for real
+  deployments are pinned with it — `AuthManager` does not plumb
+  `storeSessionInDatabase`, so the rejected dual-write shape is unreachable through
+  configuration; and the default composition (OIDC provider on) makes better-auth
+  _refuse to boot_ with a `secondaryStorage` rather than degrade quietly.
+
+  **For hosts.** `cacheSecondaryStorage()` remains exported for anyone who wants
+  better-auth's cached session store deliberately. It now says plainly what it
+  costs: opting in disables the ADR-0069 D4 session controls, and a revoked session
+  stays usable until its cached copy expires. Moving sessions into the cache
+  platform-wide would be a new decision requiring its own revocation-consistency
+  requirements, not a configuration change.
+
+  ADR-0069's D2 "shared store" is scoped to rate-limit counters, D4 records
+  `sys_session` as a precondition rather than a deployment preference, and the
+  `ICacheService` contract page no longer lists session storage among the cache's
+  uses.
+
+- ef8b1ff: fix(plugin-auth): `/sso/register` 的管理员门禁改用唯一那把等级尺,不再手抄一份大小写敏感的判据 (#5942)
+
+  ADR-0024 的 `POST /sso/register` 门禁问的是「这个 membership 是不是本组织的管理员」。
+  它此前用的是一份手抄判据:
+
+  ```ts
+  raw
+    .split(",")
+    .map((s) => s.trim())
+    .some((r) => r === "owner" || r === "admin");
+  ```
+
+  同一个问题在 plugin-auth 内还有另一把尺 —— `invitation-role-cap.ts` 的等级尺
+  (`parseOrgRoles()` 会 `.trim().toLowerCase()`,`isOrgAdminGrade()` 据此评级),
+  break-glass ban 守卫(`last-admin-ban-guard.ts`,ADR-0024 D5.2)用的就是它。
+  两把尺在大小写上不一致:`sys_member.role` 若存成 `Owner` / `ADMIN`,ban 守卫把这一行
+  算作**管理员**,而 `/sso/register` 门禁算作**非管理员**。同一条安全路径上的两个答案
+  互相矛盾,而且两个方向的错都不出声。
+
+  现在门禁改问 `isOrgAdminGrade(m.role)` —— 「哪种 membership 算管理员」在 plugin-auth
+  内只剩一个答案,两处自此同尺。
+
+  **用户可见的行为变化,只有一个方向:放宽,且只放宽在此前判错的取值上。**
+  `sys_member.role` 为大小写非常规值(`Owner` / `ADMIN` / `Admin`,以及
+  `member,Owner` 这类逗号拼写)或数组拼写(`['owner']`)的成员,此前会被
+  `/sso/register` **误拒**,现在正确判为管理员并放行。**没有任何收窄**:此前被判为管理员
+  的取值,换尺后仍然是管理员(已逐值实测,见 PR)。
+
+  ADR-0108 的封闭词表(`owner` / `admin` / `delegated_admin` / `member`)全为小写,UI 与
+  better-auth 写入的也是小写,所以正常部署下答案逐值不变 —— 这也是为什么它此前只是一条
+  静默分歧,而不是线上故障。要撞上分歧得有一条绕过表单的写入(导入、外部写入、手工 SQL)。
+
+  `isOrgOrPlatformAdmin` 名字里的 platform_admin 半边**未改动**,仍由
+  `packages/core/src/security/resolve-authz-context.ts` 权威推导;那几处实现的合流是
+  另一个决策件。
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [c36abfe]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [2f6516e]
+- Updated dependencies [64cd010]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [b746aa0]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [96d3d4d]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [08f93bc]
+- Updated dependencies [d9971d3]
+- Updated dependencies [d9cac60]
+- Updated dependencies [eb3e650]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [02dc076]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [e98fb14]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [1b9a53b]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [46365ab]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [c5adfe1]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [75f82f3]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [1203bb2]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [39396bd]
+- Updated dependencies [577cd27]
+- Updated dependencies [5897552]
+- Updated dependencies [91ec1ea]
+- Updated dependencies [2d25303]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [1216dcc]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [f104bab]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [90fa077]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/types@17.0.0-rc.4
+  - @objectstack/rest@17.0.0-rc.4
+  - @objectstack/core@17.0.0-rc.4
+  - @objectstack/platform-objects@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Minor Changes
diff --git a/packages/plugins/plugin-auth/package.json b/packages/plugins/plugin-auth/package.json
index 766a5b53fd..5c361ed1d8 100644
--- a/packages/plugins/plugin-auth/package.json
+++ b/packages/plugins/plugin-auth/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/plugin-auth",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "Authentication & Identity Plugin for ObjectStack",
   "main": "dist/index.js",
diff --git a/packages/plugins/plugin-dev/CHANGELOG.md b/packages/plugins/plugin-dev/CHANGELOG.md
index e3d756bbee..7e48310b53 100644
--- a/packages/plugins/plugin-dev/CHANGELOG.md
+++ b/packages/plugins/plugin-dev/CHANGELOG.md
@@ -1,5 +1,339 @@
 # @objectstack/plugin-dev
 
+## 17.0.0-rc.4
+
+### Patch Changes
+
+- 7e791e5: fix(plugin-dev): 请求了组织墙而企业包不可用时拒绝 init,不再只 warn 就无墙跑 (#5301)
+
+  `DevPlugin` 请求了有墙 tenancy posture(`isolated` / `group`)却加载不到企业
+  `@objectstack/organizations` 时,只打一条 `logger.warn` 就继续 boot。于是同一台机器上,
+  **同一个事实**有两个相反的答案:
+
+  | 入口                | 请求 `isolated`、企业包缺失                      | 结果                              |
+  | ------------------- | ------------------------------------------------ | --------------------------------- |
+  | `objectstack serve` | 拒绝启动(除非显式 `OS_ALLOW_DEGRADED_TENANCY=1`) | 安全                              |
+  | `DevPlugin`(改前)   | warn 后继续                                      | **无墙服务流量**,且没人显式同意过 |
+
+  ADR-0093 D5「请求了隔离就不得在没有隔离的情况下服务流量」是**部署**的性质,不是某一个
+  入口的性质,所以 dev 装配路径欠同一个答案。#5262 让这条更容易被触发而不是更难:在它之前,
+  只设 `OS_TENANCY_POSTURE` 的 dev 栈根本不进这个分支(那是 #5262 本身的缺陷),修好读数之后
+  它会进分支、会加载失败,然后正好走这条 fail-open 的路。
+
+  **改为 `throw`,不是 `process.exit(1)`。** `serve.ts` 必须 `process.exit`,因为它那道闸
+  嵌在会吞异常的 AuthPlugin `try` 里;`DevPlugin` 是**库形态**的装配插件,对宿主进程没有处置权,
+  嵌入方(测试、脚本、父应用)有权 catch 它。而且它的 boot 链不吞异常——`kernel.use()` 只登记、
+  `initPluginWithTimeout` 不 catch、`bootstrap()` 会 rethrow——所以 `throw` 能真的中止 boot,
+  与同文件 `assertNotProduction()` 的既有依据一致。
+
+  **照 #4818 分两阶段,两种失败两种诊断:**
+
+  - **阶段 1(import 失败 = 包缺失)**:`OS_ALLOW_DEGRADED_TENANCY` 生效。未设则拒绝 init,
+    报文里点名被请求的 posture 和全部出路;设了则照旧 warn 后降级继续,而且这条 warn 仍然
+    如实说明墙是 INACTIVE。判定用的是 `resolveAllowDegradedTenancy()`——和 `serve.ts`
+    同一个 resolver,所以两个入口对「显式同意」的定义不可能漂移。
+  - **阶段 2(construct / init 失败 = 包在、插件自己拒绝)**:hatch **不覆盖**,一律中止。
+    该 hatch 的含义始终是「这个能力**缺席**,我接受降级」,而不是「替我越过插件正在执行的闸」;
+    让它放行会把插件的许可证/前置条件检查降格成一个环境变量。报文原样转述插件自己的说法,
+    框架不解释,并明说这**不是**缺包问题,省掉一轮「去查安装」的排查。
+
+  阶段 2 在 `DevPlugin` 里比 `serve.ts` 多一处落点:`serve` 把插件交给 `kernel.use()`,
+  其 Phase-1 循环会 rethrow init 失败;而 `DevPlugin` 自己 init 子插件,那个循环刻意是
+  best-effort(记一条 error 继续,dev 栈才能在缺包时照常起)。对这一个子插件,best-effort
+  默认就是同一个 fail-open,所以它现在单独例外——其余子插件的容错**完全不变**。
+
+  **迁移。** 只影响「请求了有墙 posture 且企业包不可用」的 dev 栈——此前它静默降级,现在会
+  拒绝启动。若确实要在无墙状态下继续跑,显式设 `OS_ALLOW_DEGRADED_TENANCY=1`,与
+  `objectstack serve` 的做法一致。单组织(`single` posture,即默认)栈完全不受影响,
+  不进这个分支,也不需要这个 hatch。
+
+- 2ddba89: fix(tenancy): eight sites answered "is this deployment multi-org?" with the demoted `OS_MULTI_ORG_ENABLED` (#5262)
+
+  ADR-0105 D1 made `OS_TENANCY_POSTURE` the authoritative knob and demoted
+  `OS_MULTI_ORG_ENABLED` to a back-compat _input_ of `resolveTenancyPosture()`.
+  A deployment configured the documented way — `OS_TENANCY_POSTURE=isolated` (or
+  `group`), legacy boolean unset — therefore reads `false` from
+  `resolveMultiOrgEnabled()` while running a fully mounted organization wall.
+  #5233 corrected two sites in `plugin-auth`; a census found eight more, all
+  written before that function's doc comment was corrected. Third recurrence of
+  the shape (cloud#1020, #5233).
+
+  Each site was judged separately for **which** posture answers its question —
+  what the operator REQUESTED, or what the `tenancy` service reports is actually
+  IN FORCE — rather than converted mechanically:
+
+  - `objectql` `SchemaRegistry` — the env-derived multi-tenant default. Reads the
+    REQUESTED posture (it is constructed below the kernel, with no service
+    registry to ask). The `organization_id` column was always provisioned; what
+    diverged is its INDEX, so a posture-only deployment ran the Layer 0 wall's
+    hottest predicate unindexed while SecurityPlugin compiled that same wall.
+  - `plugin-dev` — whether to load the enterprise `@objectstack/organizations`.
+    REQUESTED posture, mirroring `serve.ts`: this branch is what mounts the wall,
+    so asking whether the wall is up would be circular. A posture-only dev stack
+    previously never loaded the package at all and served traffic unwalled. Its
+    diagnostic now names the posture that was requested instead of asserting
+    `OS_MULTI_ORG_ENABLED=true` at an operator who never set it.
+  - `runtime` `AppPlugin` (inline seed + hot-reload seeder) — EFFECTIVE posture,
+    via the `tenancy` service. These ask "will the per-org replay run instead of
+    me?", and on an ADR-0093 D5 degraded boot that replay does not exist, so
+    keying on the request would defer to a replay that can never happen. Walled
+    deployments previously inline-seeded exactly the NULL-organization rows the
+    code's own comment exists to avoid.
+  - `cloud-connection` marketplace local install (install-time seed + rehydrate
+    heal) — EFFECTIVE posture, same reasoning. The install path is a write path:
+    a walled deployment wrote every sample row with no `organization_id`, landing
+    the app's data outside the wall its own reads apply.
+  - `driver-sql` `isMultiTenantMode()` — REQUESTED posture (a driver has no
+    kernel to ask, and a suppressed warning is the costlier error for a
+    diagnostic). It also no longer memoises into `_multiTenantMode`: that froze a
+    process-level fact into a per-instance verdict on whichever write landed
+    first. The gate now resolves live, which is affordable because
+    `auditMissingTenant` consults it only after the `tenantId` early-out.
+  - `cli` `os verify` — REQUESTED posture. This one produced a green verification
+    run over an unverified property: a posture-only deployment silently skipped
+    every multi-tenant proof and exited 0.
+
+  **No configuration change is needed anywhere.** Deployments setting only
+  `OS_MULTI_ORG_ENABLED=true` keep working unchanged — `resolveTenancyPosture()`
+  falls back to it — and the `OS_TENANCY_POSTURE=isolated` + `OS_MULTI_ORG_ENABLED=true`
+  belt-and-braces configuration stays valid. Deployments that set only
+  `OS_TENANCY_POSTURE` can now drop the redundant boolean. Single-org behaviour is
+  unchanged at every site; only the knob each one reads is corrected.
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [da5d1b4]
+- Updated dependencies [d4e0809]
+- Updated dependencies [739f496]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [f7df82c]
+- Updated dependencies [978fed2]
+- Updated dependencies [c36abfe]
+- Updated dependencies [cfc293f]
+- Updated dependencies [d085670]
+- Updated dependencies [de70b42]
+- Updated dependencies [2f6516e]
+- Updated dependencies [01c0bae]
+- Updated dependencies [64cd010]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [7a40b7a]
+- Updated dependencies [7cf1531]
+- Updated dependencies [586d6f7]
+- Updated dependencies [9f747ee]
+- Updated dependencies [2d14b35]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [c497d26]
+- Updated dependencies [bbdbf28]
+- Updated dependencies [93929c2]
+- Updated dependencies [2e284b2]
+- Updated dependencies [3905c00]
+- Updated dependencies [4335497]
+- Updated dependencies [43ca399]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [b746aa0]
+- Updated dependencies [846ed1f]
+- Updated dependencies [947d4f9]
+- Updated dependencies [d8f65fe]
+- Updated dependencies [58ffcab]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [7bf3d1c]
+- Updated dependencies [9ce0ca9]
+- Updated dependencies [db9c331]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [217b791]
+- Updated dependencies [fd8521f]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [2b63a00]
+- Updated dependencies [06ba036]
+- Updated dependencies [18b8eaa]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [78adc2e]
+- Updated dependencies [0f17114]
+- Updated dependencies [81e2744]
+- Updated dependencies [277eb36]
+- Updated dependencies [41e605e]
+- Updated dependencies [2649ccb]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [a70cd0a]
+- Updated dependencies [c52e608]
+- Updated dependencies [96d3d4d]
+- Updated dependencies [afa6aa5]
+- Updated dependencies [afb83d3]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [c7406b0]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [08f93bc]
+- Updated dependencies [d9971d3]
+- Updated dependencies [d97f2a2]
+- Updated dependencies [d9cac60]
+- Updated dependencies [eb3e650]
+- Updated dependencies [abeb375]
+- Updated dependencies [dfa8bad]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [290d944]
+- Updated dependencies [02dc076]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [5d3ced9]
+- Updated dependencies [9fa6bab]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [61dc08e]
+- Updated dependencies [8dcf607]
+- Updated dependencies [b691ba9]
+- Updated dependencies [1eadac0]
+- Updated dependencies [7c2f7dd]
+- Updated dependencies [9b26699]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [46365ab]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [60a7a2d]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [c5adfe1]
+- Updated dependencies [26e1029]
+- Updated dependencies [1cae606]
+- Updated dependencies [4addd9d]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b9cc17d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [75f82f3]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [1203bb2]
+- Updated dependencies [7d27da0]
+- Updated dependencies [de113a4]
+- Updated dependencies [caf144a]
+- Updated dependencies [db8c285]
+- Updated dependencies [0d24078]
+- Updated dependencies [089767f]
+- Updated dependencies [5b8f95b]
+- Updated dependencies [2ddba89]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [ef7845a]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [37a8f2b]
+- Updated dependencies [441d79f]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [9c5abf4]
+- Updated dependencies [dc6abfd]
+- Updated dependencies [39396bd]
+- Updated dependencies [577cd27]
+- Updated dependencies [5897552]
+- Updated dependencies [91ec1ea]
+- Updated dependencies [2d25303]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [bf1edef]
+- Updated dependencies [7b005b4]
+- Updated dependencies [0cd08d5]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [2680cd3]
+- Updated dependencies [c5a5996]
+- Updated dependencies [b40f81c]
+- Updated dependencies [db2ea82]
+- Updated dependencies [51a587d]
+- Updated dependencies [ae490ef]
+- Updated dependencies [1216dcc]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [ef8b1ff]
+- Updated dependencies [1f1edc0]
+- Updated dependencies [718b229]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [d56bcdb]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [5aaa6fc]
+- Updated dependencies [dca5bd3]
+- Updated dependencies [488b66c]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [90fa077]
+- Updated dependencies [946a131]
+- Updated dependencies [909895d]
+- Updated dependencies [c183a12]
+- Updated dependencies [69a89ce]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+- Updated dependencies [2b52bc8]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/runtime@17.0.0-rc.4
+  - @objectstack/types@17.0.0-rc.4
+  - @objectstack/driver-memory@17.0.0-rc.4
+  - @objectstack/rest@17.0.0-rc.4
+  - @objectstack/core@17.0.0-rc.4
+  - @objectstack/plugin-hono-server@17.0.0-rc.4
+  - @objectstack/plugin-auth@17.0.0-rc.4
+  - @objectstack/objectql@17.0.0-rc.4
+  - @objectstack/plugin-security@17.0.0-rc.4
+  - @objectstack/service-storage@17.0.0-rc.4
+  - @objectstack/account@17.0.0-rc.4
+  - @objectstack/setup@17.0.0-rc.4
+  - @objectstack/service-i18n@17.0.0-rc.4
+  - @objectstack/service-realtime@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Patch Changes
diff --git a/packages/plugins/plugin-dev/package.json b/packages/plugins/plugin-dev/package.json
index e8c8e81089..68d27387f5 100644
--- a/packages/plugins/plugin-dev/package.json
+++ b/packages/plugins/plugin-dev/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/plugin-dev",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "Development Assembly Plugin for ObjectStack — wires the real platform stack for zero-config local development",
   "main": "dist/index.js",
diff --git a/packages/plugins/plugin-email/CHANGELOG.md b/packages/plugins/plugin-email/CHANGELOG.md
index 73487a5ef5..fc4a04742b 100644
--- a/packages/plugins/plugin-email/CHANGELOG.md
+++ b/packages/plugins/plugin-email/CHANGELOG.md
@@ -1,5 +1,505 @@
 # @objectstack/plugin-email
 
+## 17.0.0-rc.4
+
+### Minor Changes
+
+- bcfebb0: fix(cli,plugin-email)!: `OS_EMAIL_PROVIDER=resend/postmark` without an API key now fails the boot instead of silently becoming the log transport (#5132)
+
+  **BREAKING for one configuration: a delivery provider selected without the
+  credential it needs.** `os serve` used to answer that by rewriting `provider` to
+  `log`, printing a warning, and booting normally. The result was a server that
+  accepted every send, recorded each one in `sys_email` as sent, and delivered
+  nothing — the warning scrolled past in CI logs and the truth surfaced when a
+  user reported never receiving a verification code. #5087 closed exactly this gap
+  inside `@objectstack/plugin-email` (`makeTransport` throws rather than
+  substituting a transport); the CLI's own capability assembly kept doing it one
+  layer up, for `resend` / `postmark`.
+
+  `resolveEmailCapabilityArg` now refuses every mail configuration it cannot
+  deliver through, the way its neighbouring `smtp` arm already did:
+
+  - `resend` / `postmark` with no `OS_EMAIL_API_KEY` (or `config.email.apiKey`);
+  - a `provider` tag outside `log` / `smtp` / `resend` / `postmark` — including
+    the retired `sendgrid` / `ses`, which get their SMTP migration in the message.
+
+  **Who is affected:** deployments (typically CI or preview environments) that set
+  `OS_EMAIL_PROVIDER=resend` or `=postmark` without a key and relied on the
+  fallback to boot. Nothing else changes — a complete configuration is passed
+  through untouched, and an unset `OS_EMAIL_PROVIDER` still defaults to `log`.
+
+  **Migration — one line, either direction:**
+
+  - the environment is _not_ meant to send mail → `OS_EMAIL_PROVIDER=log`
+    (that explicit value is the supported way to say so, and why refusing the
+    others is fair);
+  - the environment _is_ meant to send mail → set `OS_EMAIL_API_KEY` (or
+    `config.email.apiKey`).
+
+  Both errors name the consequence and both fixes, per AGENTS.md's
+  degradation-log-level rule.
+
+  `@objectstack/plugin-email` gains the vocabulary the CLI reads instead of
+  restating: `API_KEY_EMAIL_PROVIDERS`, `emailProviderRequiresApiKey()` and the
+  `ApiKeyEmailProvider` type, alongside `EMAIL_TRANSPORT_PROVIDERS` /
+  `isEmailTransportProvider` / `unsupportedProviderFix` from #5094. One vocabulary,
+  two consumers, pinned by a contract test — a second literal list in the CLI is
+  how the settings dropdown and the transports drifted apart in the first place.
+
+- 9c4f174: feat(plugin-email): durable email delivery through `sys_job_queue`, opt-in (#5160)
+
+  `IEmailService.send()` has always delivered **inline**: the SMTP session ran
+  inside the caller's `await`, and `EmailService`'s retry loop lived in the same
+  process — so a crash between the attempt and the retry dropped the message with
+  no trace beyond a `sys_email` row stuck at `queued`. The pieces for a durable
+  path all existed (`sys_job_queue`, the `DbQueueAdapter`, an `email.send.async`
+  subscriber) but nothing in the repo ever published to that topic.
+
+  **New: `queueDelivery`.** With it on, `send()` persists the `sys_email` row,
+  publishes an `email.send.async` job **referencing that row**, and returns
+  `{ status: 'queued' }` immediately. A worker delivers the row and finalizes it
+  in place (`sent` + `message_id`, or `failed` + `error`); the queue retries with
+  exponential backoff (1s → 5min cap) and dead-letters the job when the attempts
+  run out, so a restart resumes delivery instead of losing it. The `'queued'`
+  status was already in `EmailDeliveryStatus` — no spec change.
+
+  Three ways to turn it on, all default-off:
+
+  - `new EmailServicePlugin({ queueDelivery: true })`
+  - `OS_EMAIL_QUEUE_ENABLED=true` (or `config.email.queueDelivery`) on `os serve`
+  - Settings → Mail → **Durable queue delivery**, hot-applied without a restart
+
+  **One retry budget, not two.** `retries` keeps its meaning — total attempts are
+  `retries + 1` in both modes. Inline it drives the in-process loop; queued it
+  becomes the queue's `maxAttempts` and the per-row loop is pinned to one attempt
+  per delivery. Turning the toggle on changes _where_ a retry happens (durable,
+  backed off) and never _how many_ happen, so the two layers cannot multiply.
+
+  **Fixed in the same change: the `email.send.async` subscriber inserted a new
+  `sys_email` row per delivery.** It called `send()` with the message, so a job
+  the queue retried five times left five rows — four permanently `failed`, none
+  carrying the real attempt count. It now delivers the referenced row via
+  `deliverPersistedRow`, so one message is one row and `attempt_count`
+  accumulates on it. Messages published in the old shape (a bare `SendEmailInput`)
+  are still accepted and delivered inline for a migration window.
+
+  Boundaries worth knowing before you switch it on:
+
+  - **"Send test email" always sends inline**, in every mode — the button has to
+    report the provider's own answer (`535 …`), and "queued" is exactly the
+    non-answer #5087 removed from it.
+  - **Messages with attachments or custom headers are delivered inline**, because
+    `sys_email` has no columns for them and a queued copy would arrive stripped.
+    Queueing them is tracked separately; this ships the loss-free behaviour.
+  - **A declaration that cannot be honoured fails the boot.** `queueDelivery: true`
+    from the constructor or `OS_EMAIL_QUEUE_ENABLED` with no durable queue
+    registered (or with `persist: false`) throws on `kernel:ready`, naming the
+    fix — the #5132 judgement, applied to durability. The **settings toggle** is
+    the opposite trade: it logs at `error` and keeps sending inline, because one
+    save must not stop the mail.
+  - The kernel's built-in in-memory `queue` fallback does **not** count as a
+    durable queue: it delivers synchronously with no retry or DLQ, so publishing
+    to it would report `queued` for a message nothing could ever recover. Mount
+    `@objectstack/service-queue` over an ObjectQL engine (the `queue` capability
+    does this on `os serve`) to get the `sys_job_queue`-backed adapter.
+
+  Leaving `queueDelivery` unset keeps today's behaviour byte for byte.
+
+- d25f20b: fix(plugin-email): `sys_email` rows stranded at `queued` are swept at boot, and a failed drain says so at `error` (#5161)
+
+  `status: 'queued'` had exactly one consumer: the `afterInsert` outbox drain that
+  fires during the insert itself (plus, since #5160, the `email.send.async` job
+  `send()` publishes). Nothing ever looked at such a row again. A process that
+  died between the insert and the delivery — or a drain whose delivery threw —
+  left the row at `queued` **forever**: a state named after a queue that had no
+  reader, while the caller had already been told the message was accepted.
+
+  **A once-per-boot sweep is now that reader.** At `kernel:ready`, after the
+  registries are settled and the `email.send.async` subscriber is attached,
+  `sweepStrandedOutbox` picks up `sys_email` rows still at `queued` and advances
+  them:
+
+  - **durable queue delivery on** → the row is published as an `{ rowId }` job to
+    `email.send.async` through the same producer, options and
+    `sys_email:<id>` idempotency key `send()` uses, so a row that still has a
+    pending job collapses onto it instead of putting a second worker on it;
+  - **inline delivery** → the row is delivered and finalized in place (`sent` /
+    `failed`), which is what the drain hook would have done had the process lived.
+
+  Only rows **older than five minutes** are eligible. A row inserted seconds ago
+  is not stranded, it is someone's in-flight work — this process's `send()`, its
+  deferred drain hook, or the same on another instance — and sweeping it would
+  send that message twice. (Age, not "created before this boot": one instance's
+  boot time says nothing about a sibling's row inserted a second ago.) Rows this
+  process is delivering right now, and rows that already carry a `message_id`, are
+  skipped. The batch is bounded at 500 rows per boot, oldest first, and says so
+  when it truncates. One `info` line reports the counts; boot does **not** wait on
+  the sweep, and a sweep that cannot run reports at `error` rather than relying on
+  `kernel:ready` error propagation.
+
+  **Drain-hook failures are now `error`, not `warn`.** A drain that throws means
+  the mail was not sent while the insert reported success and the row still reads
+  `queued` — the durability class the degradation-log-level rule pins at `error`.
+  Both lines now name the consequence (this message was NOT sent, the row stays at
+  `queued`) and the fix (the boot sweep picks it up on the next restart; turn on
+  durable queue delivery to have failures retried and dead-lettered instead).
+  `deliverPersistedRow` joins `DURABILITY_CRITICAL_CALLEES`, so a future `catch`
+  that quietly downgrades it fails `pnpm check:durability-log-level`.
+
+  New exports: `sweepStrandedOutbox`, `OUTBOX_OBJECT`, `OUTBOX_SWEEP_MIN_AGE_MS`,
+  `OUTBOX_SWEEP_LIMIT`, `EmailService.enqueuePersistedRow`, and
+  `EmailServicePlugin.outboxSweepSettled` (the sweep's promise, for callers that
+  need determinism). The normal `send()` → deliver path is byte-for-byte
+  unchanged.
+
+- 1b9a53b: plugin-email: large attachments (>256 KiB) now get durable queue delivery, with their content held out of the `sys_email` row
+
+  A message whose attachments exceeded the in-row budget was pushed back onto inline delivery — whole, but with none of the durability queue delivery exists to provide, which meant the platform was weakest about exactly the mail that matters most (a signed contract, an exported report). Its content now goes to the `file-storage` capability, the row records a `storageKey` plus the audit metadata, and the queue worker fetches the content back to rebuild the message.
+
+  - **Zero migration.** `attachments_json` declared `storageKey` from the start; this adds the producer and the reader. Attachments at or under `SYS_EMAIL_ATTACHMENT_LIMIT_BYTES` still go in the row exactly as before, and the boundary includes equality.
+  - **The row stays an audit log, not a blob store.** `filename` / `contentType` / `size` / `hash` stay on the row permanently; the content is a delivery artifact and is deleted a grace window (24h) after the row reaches a terminal state, at which point `storageKey` is replaced by `contentReclaimedAt`. Reclamation is a delayed `email.attachment.reclaim` queue job that carries the storage keys, so a row deleted in the meantime reclaims its content instead of orphaning it.
+  - **Nothing degrades silently.** No `file-storage` capability, or an upload that fails, keeps today's behaviour — inline delivery of the whole message — and says which of the two it was and how to fix it. On the way back, content that cannot be fetched (outage, missing object, no capability on the worker, truncated or substituted bytes) fails the row loudly; a message is never delivered without an attachment it declares.
+
+- 8597a7d: fix(service-settings,plugin-email): the mail provider dropdown lists only providers that actually deliver (#5094)
+
+  **Settings → Mail → Provider** offered `SMTP | SendGrid | Amazon SES | Postmark`.
+  `@objectstack/plugin-email` has never carried a SendGrid or an SES transport —
+  `makeTransport` knows `log` / `resend` / `postmark` / `smtp` and nothing else. So
+  selecting either of the two validated, saved, showed a success toast, and then
+  delivered no mail at all: the same declared-but-not-delivered gap #5087 closed
+  for SMTP, one field to the left.
+
+  The same field broke the invariant in the other direction at the same time:
+  **`resend` has shipped a working transport all along and was not on the list**,
+  so nobody could pick the one HTTP provider that worked.
+
+  **The dropdown is now `SMTP | Resend | Postmark | None (log only — no real
+delivery)` — exactly the set `makeTransport` can build.** No email capability was
+  removed with SendGrid and SES. Both publish SMTP endpoints, and #5087 shipped a
+  real `SmtpTransport`, so both are configured today as `smtp`:
+
+  | provider   | host                                | port | credentials                                                                        |
+  | :--------- | :---------------------------------- | :--- | :--------------------------------------------------------------------------------- |
+  | SendGrid   | `smtp.sendgrid.net`                 | 587  | username `apikey`, password = your API key                                         |
+  | Amazon SES | `email-smtp.<region>.amazonaws.com` | 587  | SES **SMTP credentials** (generated in the SES console — not your AWS access keys) |
+
+  The provider field's own description says this, so the migration is in front of
+  whoever goes looking for the option that disappeared.
+
+  `log` is listed rather than hidden. It is the one option that does not deliver —
+  but it does not pretend to: the label says so, `LogTransport` still records every
+  message to `sys_email`, and "Send test email" answers `ok: false` for it. That
+  gives an operator the deliberate, visible opt-out AGENTS.md asks a degradation to
+  be, instead of expressing "no outbound mail" as a half-filled SMTP form. It is
+  also what makes _offered_ and _deliverable_ the same set rather than merely
+  overlapping — which is the property a test can hold.
+
+  **Already saved `sendgrid` or `ses`? Nothing breaks and nothing goes quiet.** The
+  stored value outlives the dropdown, so `applyMailSettings` now recognises it
+  explicitly: the previous transport is kept (a settings row written by an older
+  release must never fail a boot), and the server logs at `error` with both halves
+  AGENTS.md requires — the consequence (_no mail is delivered through it_) and the
+  fix (the SMTP settings above), not a bare "unknown provider". It is checked
+  _before_ the API-key check, because "set an API key" is the wrong instruction for
+  a provider that has nothing to hand a key to. "Send test email" refuses the same
+  way and sends nothing. Switching the provider to `smtp` and saving recovers the
+  transport without a restart.
+
+  Two smaller corrections in the same field:
+
+  - `api_key` is now shown and required for exactly `resend` and `postmark`
+    (`provider === 'resend' || provider === 'postmark'`). It was `provider !==
+'smtp'`, which only worked because every non-SMTP option happened to be an
+    HTTP API; `required` is enforced server-side wherever the field is visible, so
+    that expression would have refused to save "None (log only)" until an API key
+    it never reads had been typed in.
+  - The built-in `mail/test` fallback (the one that runs when no email plugin is
+    mounted) rejects any `provider` outside the manifest's own option list instead
+    of answering "the form is well-formed".
+
+  **Held by a test, in both directions.** `EMAIL_TRANSPORT_PROVIDERS` is now a
+  runtime array (the `EmailTransportProvider` union is derived from it), and
+  `plugin-email`'s `mail-manifest-providers.contract.test.ts` asserts set equality
+  between it and the manifest's option values, then builds a real transport for
+  each. Adding an option without a transport fails; adding a transport without an
+  option fails. `RETIRED_EMAIL_PROVIDERS` / `isEmailTransportProvider` /
+  `unsupportedProviderFix` are exported alongside it for hosts that surface the
+  same guidance.
+
+- 41c3b48: feat(plugin-email): real SMTP delivery — `SmtpTransport`, settings hot-swap, and a `mail/test` that actually sends (#5087)
+
+  The **Mail Delivery** settings page has always defaulted to SMTP and offered a
+  full host / port / TLS / username / password form. Nothing behind it delivered:
+  `applyMailSettings` treated `provider: 'smtp'` as a no-op ("transport
+  unchanged"), `mail/test` answered `ok: true, "Configuration looks valid … Wire
+@objectstack/plugin-mail for actual delivery"` — a success toast for a message
+  nobody sent, naming a package that has never existed — and the code pointed
+  operators at `@objectstack/plugin-mail-smtp`, which is not in this repo or on
+  npm. A workspace that selected SMTP got a green form, a green test button, and
+  mail that only ever reached the log and the `sys_email` table. For deployments
+  in China this left **no** working channel at all: Resend and Postmark are
+  overseas HTTPS SaaS with unreliable reach and deliverability to QQ / 163 /
+  enterprise mailboxes, where SMTP is the normal path (Aliyun DirectMail, Tencent
+  SES, corporate mail servers).
+
+  **`SmtpTransport` now ships in `@objectstack/plugin-email`** (ADR-0012: SMTP in
+  core, implemented with `nodemailer`). `nodemailer` is a real dependency but is
+  imported **lazily on the first send**, so deployments that never select SMTP —
+  and non-Node runtimes — never load `node:net` / `node:tls`.
+
+  Three doors reach it, all sharing one options reader so they cannot drift:
+
+  - **Settings → Mail** (`smtp_host` / `smtp_port` / `smtp_secure` / `smtp_user` /
+    `smtp_password`) hot-swaps the live transport on save, no restart.
+  - **`os serve`** via `OS_EMAIL_PROVIDER=smtp` plus the new `OS_EMAIL_SMTP_HOST` /
+    `_PORT` / `_SECURE` / `_USER` / `_PASSWORD` (or `config.email.options`).
+  - **Constructor**: `new EmailServicePlugin({ provider: 'smtp', providerOptions:
+{ host, port, secure, user, password } })`.
+
+  TLS is one toggle with the wire behaviour derived from the port, as providers
+  document it: on `465` implicit TLS (SMTPS); on any other port a **required**
+  STARTTLS upgrade, so a server that refuses to upgrade fails the send instead of
+  leaking credentials over a cleartext socket; `secure: false` connects in the
+  clear and upgrades only when STARTTLS is offered.
+
+  **Failure is loud everywhere, because a silent fallback is the bug this fixes.**
+  On the construction path (CLI / plugin options) a `smtp` provider with no host
+  **throws** and the boot fails — it no longer degrades into a LogTransport that
+  reports every send as successful. On the settings hot-swap path a save can never
+  kill a running server, so the previous transport is kept — but the failure is
+  logged at `error` naming the consequence and the fix, and **`mail/test` now
+  performs a real delivery** through the settings on screen and reports the SMTP
+  server's own words (`535 … authentication failed`) instead of a green toast. The
+  built-in fallback `mail/test` handler (used only when no email plugin is
+  mounted) answers `ok: false` and says plainly that nothing was sent.
+
+  Nothing to migrate: `log`, `resend` and `postmark` behave exactly as before, and
+  a deployment that never selects `smtp` is unaffected.
+
+- f104bab: feat(plugin-email,platform-objects): `sys_email` carries headers and small attachments, so those messages become durably deliverable (#5177)
+
+  Durable email delivery works from the **row**, not from the in-memory message:
+  `send()` publishes an `{ rowId }` job (#5160), the boot sweep re-reads rows
+  (#5161), and both end at `rowToNormalized`. So anything a `sys_email` row could
+  not carry, a row-based delivery would have dropped — and custom headers and
+  attachments were exactly that. The honest workaround was to refuse: a message
+  with either was pushed back onto inline delivery so that it would at least go
+  out whole, which closed the durable path to precisely the mail most worth
+  making durable (a signed receipt, a `List-Unsubscribe` header, an invoice PDF).
+
+  `sys_email` now has two columns, and those messages are queueable.
+
+  **`headers_json`** — the custom headers, as a JSON object. Written in both
+  delivery modes (it is audit evidence as much as delivery input) and rebuilt on
+  read. Headers are no longer a reason to fall back to inline delivery.
+
+  **`attachments_json`** — attachments as a JSON array of
+  `{ filename, contentType?, size, hash, cid?, contentForm, inline?, storageKey? }`,
+  content base64 in `inline`. Written when the **combined raw size of one
+  message's attachments is within `SYS_EMAIL_ATTACHMENT_LIMIT_BYTES` (256 KiB,
+  exported from `@objectstack/plugin-email`)** — worst case ~350 KB of base64, so
+  a row stays bounded. Both arms of the declared `content: string | Buffer`
+  contract round-trip as the arm they were sent as: restoring a text attachment
+  as a Buffer would silently drop `charset=utf-8` from its MIME part and let the
+  recipient's client mis-decode a UTF-8 file, so `contentForm` records which one
+  it was. `cid` travels too — an inline `<img src="cid:…">` is unusable without
+  it.
+
+  **Over the limit, nothing changes.** The message is delivered inline exactly as
+  before, whole, and the row stores no attachment content; the reason is stated
+  at `info` (a bound, not a degradation — the worst outcome is today's
+  behaviour). Out-of-row storage for large attachments is #5172; `storageKey` is
+  declared now so that lands as a new _producer_ rather than a data migration.
+
+  Rows written before these columns exist read exactly as they did. A column that
+  is present but does not describe what it claims — malformed JSON, a size or
+  hash that disagrees with the content, a missing `contentForm` — is **rejected**,
+  and the row lands at `failed` carrying the reason, rather than being delivered
+  with a part quietly missing.
+
+  The `sys_email` schema change is additive (two optional textarea columns); no
+  migration is required and default inline delivery is unchanged.
+
+### Patch Changes
+
+- 205e81b: fix(plugin-email)!: `EmailPersistence.insert` must return the row's own id — a substituted id is rejected instead of double-sending (#5523)
+
+  **FROM** — `insert` could answer with an id of its own (a database-assigned
+  primary key, an external delivery system's receipt id) and `EmailService.send()`
+  adopted it: the substituted id was added to the service-managed set, used as the
+  queued job's `rowId`, and returned to the caller.
+
+  **TO** — `insert` must confirm the id it was handed. Returning a different id
+  throws, naming the contract and the value returned, **before the message is
+  delivered**.
+
+  **Fix, one line:** return `{ id: row.id }` (or `row.id`) from `insert`. If your
+  store assigns its own primary key, keep the service-minted id in the row's `id`
+  column and record the store's key in a column of its own.
+
+  Why the contract tightened rather than the service accommodating both: the id is
+  minted by the service _before_ the insert and is already load-bearing by the time
+  `insert` is called — out-of-row attachment content has been uploaded under
+  `sys_email/attachments/<row.id>/…`, so the row id is the only key that finds
+  those bytes again. Re-keying the row also broke delivery exactly-once: the
+  `sys_email` `afterInsert` outbox drain hook decides whether a freshly-inserted
+  row is the service's to deliver by asking `isServiceManaged()` about **the
+  inserted row's own id**, and that hook runs _inside_ the insert — before `send()`
+  had seen, let alone reserved, the substituted id. So the hook read the row as an
+  application-inserted outbox entry and delivered it, while `send()` delivered it
+  again down its own path: one message sent twice, two terminal updates racing on
+  one row. The only thing that ever prevented it was the hook's `setTimeout(…, 0)`
+  losing a race to `send()`'s inline delivery — and `transport.send` is real
+  network I/O, so that race is normally lost.
+
+  Scope of the check: it judges the confirmation's **value**, not its presence. An
+  implementation that returns no id at all leaves nothing to disagree with (the
+  drain hook reads the id off the inserted row, which is the minted one either
+  way), so the mail still goes. An insert that _throws_ is unchanged — that stays
+  an operational condition the service rides out with a warning and inline
+  delivery; only a _successful_ insert that renames the row is fatal.
+
+  Breaking for external `EmailPersistence` implementations that re-key the row —
+  of which there are currently none: the in-repo implementation forwards the
+  engine's own answer and ObjectQL honours the id it is handed. Filed at `patch`
+  because the surface has no known external consumer and the declared TypeScript
+  signature is unchanged; a maintainer who counts a narrowed public-interface
+  contract as `minor`/`major` should relabel it.
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [b746aa0]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [0f17114]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [58f3220]
+- Updated dependencies [07f1822]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [d9971d3]
+- Updated dependencies [eb3e650]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [e98fb14]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [1b9a53b]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [46365ab]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [c5adfe1]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [bf1edef]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [f104bab]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/core@17.0.0-rc.4
+  - @objectstack/platform-objects@17.0.0-rc.4
+  - @objectstack/formula@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Minor Changes
diff --git a/packages/plugins/plugin-email/package.json b/packages/plugins/plugin-email/package.json
index f90da10213..1ee31c814a 100644
--- a/packages/plugins/plugin-email/package.json
+++ b/packages/plugins/plugin-email/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/plugin-email",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "Email service plugin for ObjectStack — IEmailService + transport-pluggable outbound delivery with sys_email persistence.",
   "main": "dist/index.js",
diff --git a/packages/plugins/plugin-hono-server/CHANGELOG.md b/packages/plugins/plugin-hono-server/CHANGELOG.md
index 56225a761d..13477c3dd7 100644
--- a/packages/plugins/plugin-hono-server/CHANGELOG.md
+++ b/packages/plugins/plugin-hono-server/CHANGELOG.md
@@ -1,5 +1,448 @@
 # @objectstack/plugin-hono-server
 
+## 17.0.0-rc.4
+
+### Major Changes
+
+- 29c6c9d: feat(spec,core,runtime)!: declarative `apis:` refuses loudly instead of parsing into silence; the `ApiRegistry` family retires (#4936, #4939)
+
+  The declarative API-endpoint surface was **zero-execution end to end**, and said nothing
+  about it. Metadata loading worked perfectly — a stack declared `apis:`, `defineStack`
+  accepted it, and `GET /api/v1/meta/api` returned every endpoint with every key intact.
+  The execution side never fired once. On a real boot (showcase, 47 plugins) both declared
+  paths answered a bare `404 {"error":"Not found"}` — not even the dispatcher's semantic
+  404, because **no route was ever mounted** for a declared path, so the request died at
+  Hono's `notFound`. Behind that, the dispatcher's `handleApiEndpoint` branch resolved the
+  metadata service and called `matchEndpoint` on it — a method **no implementation in the
+  repo has ever provided**. The branch returned "not handled" on every request ever served.
+
+  So every key on `ApiEndpointSchema` was declared ≠ enforced: `path`/`method` (never
+  mounted), `type`/`target`/`objectParams` (never executed), `cacheTtl`,
+  `inputMapping`/`outputMapping`, `rateLimit`, `summary`/`description` — and
+  **`authRequired`**, a security semantic that parsed green and gated nothing at all. That
+  is false compliance, the failure ADR-0049 exists to stop, not debt.
+
+  ## BREAKING — a non-empty `apis:` is now rejected
+
+  Metadata that parsed cleanly before is now **refused at publish/validate**, with the
+  prescription in the rejection itself:
+
+  ```
+  apis: `apis:` (declarative ApiEndpoint) is DECLARED BUT NOT EXECUTABLE in this runtime,
+  so a non-empty array is rejected instead of silently accepted (#4936). …
+  ```
+
+  **FROM → TO.** `apis: [ …endpoints… ]` → `apis: []` (or delete the key; both are still
+  accepted, and an empty array is not a special case). To actually serve the route today,
+  mount it **in code** — a plugin manifest `contributes.routes` entry, or an `http.server`
+  route. That is now the only honest path, and the one `examples/app-showcase` uses
+  (`src/system/server/recalc-endpoint.ts`).
+
+  The refusal lives on `ObjectStackDefinitionSchema` itself, which is the single choke
+  point every path runs through — `defineStack`, the metadata plugin's artifact ingestion,
+  `os validate`, the lint scorer and `EnvironmentArtifactSchema`. There is no path that
+  forgot to check.
+
+  **The `ApiEndpoint` vocabulary is deliberately KEPT.** Retiring it was considered and
+  rejected: endpoint shapes are an industry-stable form, so a retirement would only mean
+  re-introducing the identical schema later. Your endpoint definitions stay valid TypeScript
+  and stay in the spec; only _authoring them into a stack_ is refused, and only until the
+  executor lands. Keep them commented next to your stack — that is what the showcase does.
+  The executor (route mounting + endpoint matching + per-key wiring for
+  `authRequired`/`cacheTtl`/`inputMapping`/`outputMapping`/`rateLimit`) is tracked by
+  **#5040**, which replaces this rejection with real execution.
+
+  ## BREAKING — the `ApiRegistry` / `ApiEndpointRegistration` family is removed (#4939)
+
+  The repo carried a **second**, unrelated declaration shape for "an API endpoint":
+  `ApiEndpointRegistrationSchema` and the ~500-line `ApiRegistry` service that
+  `createApiRegistryPlugin()` registered under `api-registry`. Nothing composed it — every
+  assembly site lived in `packages/core/examples/`, with no registration in
+  `packages/runtime`, `packages/cli` or any `examples/app-*`, and a real boot carried no
+  such service. The whole family was therefore inert, including
+  `ApiEndpointRegistration.requiredPermissions`, whose docs promised **in the present tense**
+  that "the gateway layer automatically validates these permissions" while no gateway read
+  it. Two declaration shapes, both dead; this retirement converges them on one.
+
+  Removed from `@objectstack/spec/api`: `ApiEndpointRegistration(Schema)`,
+  `ApiRegistry(Schema)`, `ApiRegistryEntry(Schema)`, `ApiMetadataSchema`,
+  `ApiParameterSchema`, `ApiResponseSchema`, `ApiDiscoveryQuerySchema`,
+  `ApiDiscoveryResponseSchema`, `ApiProtocolType`, `HttpStatusCode`,
+  `ObjectQLReferenceSchema`, `SchemaDefinition` (12 JSON-Schema defs, 67 authorable keys).
+  Removed from `@objectstack/core`: `ApiRegistry`, `createApiRegistryPlugin`.
+  Removed from `@objectstack/plugin-hono-server`: the `useApiRegistry` option — it was
+  defaulted to `true` and read by nothing, configuring a service that was never composed.
+
+  **FROM → TO.** There is no replacement shape to migrate to, because nothing executed the
+  old one: delete the registration objects. If you were assembling an `ApiRegistryEntry`,
+  you were building a value only your own code read — keep it as your own type. Declarative
+  endpoints have one vocabulary now, `ApiEndpointSchema`.
+
+  `ConflictResolutionStrategy` **survives** the removal and moved to
+  `@objectstack/spec/api`'s `router.zod` — same name, same four values
+  (`error`/`priority`/`first-wins`/`last-wins`), same import path. It is pinned there by two
+  independent ratchets and is not part of the retired surface.
+
+  ## Also in this change
+
+  - **BREAKING (`@objectstack/runtime`):** `HttpDispatcher.handleApiEndpoint()` is deleted,
+    along with its now-orphaned private `callData` delegate, and `/__api-endpoint` leaves
+    `LEGACY_CHAIN_PREFIXES` and the route ledger. The method was public, so this is an API
+    removal — but it returned `{ handled: false }` for every call it ever received, so no
+    caller can observe a behaviour change beyond the missing symbol. Delete the call.
+    Absence is now loud (ADR-0076): the surface is refused at authoring rather than 404ing
+    at runtime with dead code behind it.
+  - `examples/app-showcase` no longer declares endpoints, and its coverage manifest no
+    longer claims the capability is `demonstrated` — that entry read "executed by the runtime
+    dispatcher (handleApiEndpoint)", which was exactly the advertise-what-you-don't-deliver
+    claim Prime Directive #10 forbids.
+  - The endpoint-level `rateLimit` tracking pointers left by #4910/#5006 now name **#5040**,
+    the live executor card, instead of #4936, which closes with this change.
+
+### Minor Changes
+
+- 2649ccb: feat(runtime,hono): 挂载 seam —— `setFallbackHandler` 实现 + 声明式端点派发步(#5040 E3, #5090)
+
+  给声明式 `apis:` 端点铺上**唯一一条**能进入处理器的通路,并且这条通路在构造上不可能遮蔽任何
+  已注册路由。执行器本身尚未落地,本次改动**零现网行为变更**:任何 stack 目前都无法发布非空
+  `apis:`(publish 硬拒,直到 #5040 E7 翻转),所以这里新增的一切在真实组合里结构性不可达。
+
+  **`@objectstack/plugin-hono-server` —— `IHttpServer.setFallbackHandler` 的实现**
+
+  契约(#5080 落在 `@objectstack/spec/contracts`)的四条保证逐条兑现:
+
+  - 映射到 Hono 的 `app.notFound` 钩子,**不是**通配路由。这是全部要点:通配路由要与之后注册
+    的每一条路由竞争,而 Hono 按先注册者赢裁决,归属就变成插件 `start()` 顺序的函数 ——
+    ADR-0076 D11 正是为此存在。兜底器只在全部显式路由未命中后运行,**零注册顺序依赖**。
+  - handler 拿到的 `req.body` **可读**(与 `use()` 中间件 seam 相反,后者的契约明确不填充
+    body),按 content-type 解析,与真实路由处理器走同一段代码。
+  - 重复安装即**替换**,不成链。
+  - handler 不写响应 → 适配器既有的未命中答案(404,或方法不匹配时 405 + `Allow`)原样保留。
+
+  配套的一处属主收敛:404/405 应答此前由 `HonoServerPlugin.start()` 直接写在
+  `getRawApp().notFound(...)` 上。`app.notFound` 是后调用者覆盖,兜底 seam 落在同一个钩子上,
+  两个写入方意味着幸存者由插件启动顺序决定 —— 应答本体因此移入 `HonoHttpServer`
+  (`installNotFoundSeam()` / `setFallbackHandler()` 在其中组合),一个钩子一个属主。行为
+  逐字节不变(`notfound-405.test.ts` 原样通过)。
+
+  顺带修好同一段代码上的两处不一致:适配器构造的 `IHttpRequest` 现在一律带
+  `remoteAddress`(此前只有中间件 seam 有,同一个契约有两种形状);处理器**同步**抛出与
+  异步 reject 现在报同一种结果(此前同步抛出会逃到 Hono 自己的错误页)。
+
+  **`@objectstack/runtime` —— dispatcher 端点派发步**
+
+  dispatcher-plugin 在 `start()` 中探测 `typeof server.setFallbackHandler === 'function'`
+  并注册兜底器。对落在 ADR-0121 D1 保留段 `<prefix>/apps/<命名空间>/<子路径>` 下的请求,
+  探测 `metadata` 服务的 `matchEndpoint`(#5089 的实现在并行开发,探测缺席即穿透):
+
+  - **命中** → `501 NOT_IMPLEMENTED`,包络说明执行器随 17.x 落地(#5040 E4–E5 接策略键与
+    执行目标);
+  - **未命中 / 无 matcher / 无 metadata 服务 / 路径不在挂载前缀下** → **不写任何响应**,
+    传输层既有的 404/405 答案原样成立(有回归测试逐字节钉住);
+  - `matchEndpoint` 抛错按 5xx 出口应答,不降级为 404 —— 故障不得伪装成「没有这条路由」。
+
+  派发步**不重入** `dispatch()`:那条管线会解析环境与 `executionContext`、跑匿名拒绝门、并以
+  语义 404 收尾,把全部未命中请求灌进去会改变今天未命中请求的答案。裸 404 与语义 404 的收口
+  是另一个决定,本次刻意不做。
+
+  `route-ledger.ts` 新增 `* /apps/**` 登记行与 `NON_DISPATCH_MOUNT_PREFIXES`(本包在
+  `dispatch()` 之外挂载的前缀),注记如实描述已接线的部分与**尚未**接线的执行部分;新增
+  一致性测试钉住 ADR-0121 D1 赖以成立的事实 —— `/apps` 不属于任何内建域。
+
+- 55dbbba: feat(spec,runtime,hono): `server.security.rateLimit` — an authored budget that actually returns 429 (#4910, #4937)
+
+  Rate limiting in ObjectStack was three shapes with nothing between them. `packages/spec`
+  declared `RateLimitConfig` in three places and the whole repo had **zero readers** for any
+  of them, so an author wrote a budget, it parsed, and nothing happened (#4686).
+  `@objectstack/runtime` shipped a token bucket whose comments claimed, in the present tense,
+  that the dispatcher called it and short-circuited with 429 — it had **zero call sites**
+  outside its own unit test, and the `DispatcherPluginConfig.rateLimit` field it told you to
+  tune did not exist (#4937). Neither half was broken; they were simply never connected, and
+  both were documented as if they were.
+
+  They are connected now, along one narrow path.
+
+  ## What you write
+
+  ```ts
+  export default defineStack({
+    manifest: {
+      /* … */
+    },
+    server: {
+      security: {
+        rateLimit: { enabled: true, windowMs: 60_000, maxRequests: 600 },
+      },
+      trustProxy: false,
+    },
+  });
+  ```
+
+  `server:` is a **new** top-level stack key. Nothing declared it before, so no existing
+  stack changes behaviour on upgrade — there is no configuration that was inert yesterday
+  and starts throttling today.
+
+  It is deliberately **narrow**: it carries `security.rateLimit` and `trustProxy` and
+  nothing else, because those are the two keys with a consumer. It is NOT the nine-key
+  `HttpServerConfigSchema` — the other seven have no reader and no authoring surface, and
+  mounting them here would have made seven dead keys writable in one move (their
+  enforce-or-remove fate stays with #4938). It is strict from birth (#4001), so a misspelled
+  budget is rejected with the correction rather than silently defaulted, and `maxRequests: 0`
+  is refused at `defineStack` rather than at 3am.
+
+  **No `server.port`.** The listening socket belongs to the deployment, not the artifact, and
+  `objectstack serve -p` already owns it. The precedence rule is recorded in the schema and
+  the docs in advance, so it cannot be re-litigated per caller: **CLI flag > `server:` >
+  built-in default.**
+
+  ## What happens
+
+  Every inbound request the server routes — REST, dispatcher, service routes, anything
+  mounted on that transport — consumes from a token bucket sized `capacity = maxRequests`,
+  refilling at `maxRequests / (windowMs / 1000)` per second. An empty bucket answers **429**
+  with a `Retry-After` computed from the bucket itself and the standard error envelope
+  (`code: "RATE_LIMIT_EXCEEDED"`). `OPTIONS` preflights are never metered.
+
+  The bucket is keyed by **resolved principal**, falling back to the caller's **IP** for
+  anonymous traffic — so one abusive session cannot spend another user's budget, and
+  credential-stuffing traffic (which has no principal yet) is still metered per source. That
+  IP comes from `X-Forwarded-For` / `X-Real-IP` **only when `trustProxy: true` is declared**;
+  otherwise it is the transport's own peer address. Undeclared, those headers are attacker
+  input: honouring them by default would hand anyone an unlimited supply of fresh buckets and
+  let them drain a chosen victim's.
+
+  Counters live in the kernel `cache` service when one is registered, so a multi-node
+  deployment enforces one budget instead of one per node (ADR-0069 D2), resolved lazily at
+  consume time so a cache plugin that registers later is still picked up (#4772). With no
+  cache service at all it falls back to a per-process store and says so once, naming the
+  consequence: the effective limit becomes the declared budget multiplied by the number of
+  nodes, and nothing about the deployment looks wrong.
+
+  ## Also in this change
+
+  - **`IHttpServer.use()` is a real middleware seam.** The Hono adapter's implementation
+    passed `{}` for both `req` and `res` and called `next()` unconditionally, so a registered
+    middleware could not read the request, write a response, or decline to continue — a
+    declared seam with no execution behind it, unnoticed because nothing called it. It now
+    delivers method/path/query/headers plus the transport peer address
+    (`IHttpRequest.remoteAddress`, new), and honours a short-circuit. Middleware must be
+    registered before the routes it guards; the kernel's two-phase boot makes that automatic
+    (`init()` before every `start()`).
+  - **`packages/runtime/src/security/rate-limit.ts` no longer describes an execution chain it
+    does not have** (#4937). The token-bucket arithmetic is extracted so the synchronous
+    in-process limiter and the new shared-store one cannot drift, and `DEFAULT_RATE_LIMITS` is
+    now labelled as the reference material it always was rather than as live defaults.
+
+  ## Explicitly NOT wired
+
+  `ApiEndpointSchema.rateLimit` and `ApiEndpointRegistrationSchema.rateLimit` remain
+  **known-unwired**. Declaring them still changes nothing. They are not retired here either:
+  the fate of the whole declarative `apis:` surface is undecided (#4936), and retiring one
+  key of a surface that may yet be implemented would only have to be undone. Tracked, not
+  silent.
+
+### Patch Changes
+
+- dfa8bad: 修复:逃出路由 handler 的抛出不再被静默丢弃 —— 适配器接缝现在有诊断出口
+
+  `HonoHttpServer.runHandler()` 的兜底 `.catch` 此前把 rejection 显式丢弃(参数名就是 `_err`),`wrap()` 随后回一个 `{ error: 'No response from handler' }` 的 500。净效果是:**任何**逃出 handler 的抛出,在以本适配器为 transport 的 host 上都表现为一个不带原因的裸 500,而且**任何地方都没有日志** —— 连 stack 都没有。
+
+  现在该接缝会按 `Logger` 契约打一条 `error` 记录,带上原始 `message` / `stack` 与定位所需的请求上下文(`method` + `path`)。
+
+  - **`Error` 走契约的 `error` 形参槽**,不塞进结构化 meta。`Error` 的 `message` / `stack` 是 non-enumerable,直接进 meta 会序列化成 `{}` —— 那比没有日志更糟,因为它会报告成功。跨 realm 的 `Error`(`instanceof` 不成立)会按 `name`/`message`/`stack` 重建;`throw 'boom'` 这类非 `Error` 抛出会被描述进 message 而不是丢掉。
+  - **请求体不入日志** —— 只有 `method` 和 `path`。
+  - **默认就有日志出口。** 未接线时适配器用 `createLogger()`,而不是静默:直接内嵌 `HonoHttpServer` 的 host(serverless 入口)正是本问题的生产现场,静默默认会对它们原样复现该 bug。`HonoServerPlugin.init()` 会用 `ctx.logger` 替换掉默认值;要静默须显式传 `NoopLogger`。
+
+  新增 `HonoHttpServer.setLogger(logger)`(纯新增,不改 `IHttpServer` 契约)。
+
+  ⚠️ **响应形状一字未改**:兜底 body 仍是 `{ error: 'No response from handler' }` + 500,已加测试钉住。把它收成声明信封会改变线上响应形状,属另一项尚未裁决的契约决策,不随本次改动附带。
+
+- caf144a: ci(deps): OSV security batch 2026-08 — undici to 7.29.0, hono to 4.12.34,
+  fast-uri to 3.1.5, so `Validate Package Dependencies` stops failing on every PR (#5032)
+
+  Eight advisories (2 high, 6 medium) matched packages resolved in `main`'s
+  `pnpm-lock.yaml`, and all eight name a fixed version:
+
+  | advisory              | CVSS | package    | resolved         | fixed   |
+  | --------------------- | ---- | ---------- | ---------------- | ------- |
+  | `GHSA-7p8r-x3mc-p8w7` | 7.5  | `fast-uri` | 3.1.4            | 3.1.5   |
+  | `GHSA-8j4g-w8fx-2239` | 5.3  | `hono`     | 4.12.32, 4.12.33 | 4.12.34 |
+  | `GHSA-4cwx-7wf7-3272` | 7.4  | `undici`   | 7.28.0           | 7.29.0  |
+  | `GHSA-jr45-8vmc-qm54` | 5.9  | `undici`   | 7.28.0           | 7.29.0  |
+  | `GHSA-8xcm-r25x-g524` | 4.8  | `undici`   | 7.28.0           | 7.29.0  |
+  | `GHSA-v3r7-h72x-cjcm` | 4.8  | `undici`   | 7.28.0           | 7.29.0  |
+  | `GHSA-m8rv-5g2x-5cg5` | 4.2  | `undici`   | 7.28.0           | 7.29.0  |
+
+  The OSV-Scanner step in `.github/workflows/validate-deps.yml` reads
+  `pnpm-lock.yaml` directly and exits non-zero on any match, so the job was red on
+  `main` itself and attached that red to every PR touching a manifest or the
+  lockfile, whatever the PR contained (observed on #5027, whose own lockfile delta
+  is three lines and resolves no new package). A permanently red gate is worse
+  than no gate: the next PR that really does introduce a vulnerable dependency
+  looks exactly like all the others.
+
+  `undici` repeats the trap #4945 taught. The existing pin
+  (`undici@>=7.23.0 <7.28.0: ^7.28.0`, added for `GHSA-vmh5-mc38-953g`) had
+  settled on 7.28.0 — the version these five advisories affect — and its exclusive
+  upper bound no longer covered it, so the override sat there doing nothing.
+  Selector and target move together, to `<7.29.0` / `^7.29.0`. Transitive-only via
+  `@vscode/vsce` > `cheerio`; `@ai-sdk/provider-utils` already resolved 7.29.0, so
+  the two dedupe onto one copy. `jsdom`'s `undici` 8.9.0 is outside the selector
+  and untouched.
+
+  `fast-uri` is transitive-only through `ajv@8.20.0` (declares `^3.0.1`), reaching
+  `@modelcontextprotocol/sdk`, `@objectstack/objectql`, `secretlint` and `table`;
+  a `fast-uri@<3.1.5: ^3.1.5` override covers all of them.
+
+  `hono` is the one that is not transitive-only, which is why this changeset
+  releases something. Two versions were resolved: 4.12.32 from our own packages
+  and 4.12.33 pulled by `@modelcontextprotocol/sdk`. The override moves the
+  transitive copy and the declared ranges move with it — `@objectstack/plugin-hono-server`
+  `dependencies.hono` to `^4.12.34` (the published-manifest change this patch
+  covers), plus the `@objectstack/hono` and `@objectstack/plugin-auth`
+  devDependencies. Overrides do not ship with published packages, so a declared
+  range left behind would mean downstream resolves a version CI never ran —
+  exactly what `scripts/check-override-consistency.mjs` exists to catch. The
+  `@objectstack/hono` **peer** range stays the permissive `^4.12.8` on purpose: a
+  peer states which host `hono` the adapter works against, and a host that pins an
+  old one owns that copy. After the bump the workspace resolves a single
+  `hono@4.12.34`.
+
+  Scope is the eight advisories #5032 lists and nothing else. #4965 (advisories
+  with no fix available, and the `osv-scanner.toml` exemption conventions that
+  answer them) is a separate question — every advisory here has a fix, so this is
+  an upgrade, not an exemption.
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [64cd010]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [b746aa0]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [08f93bc]
+- Updated dependencies [d9971d3]
+- Updated dependencies [eb3e650]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [02dc076]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [46365ab]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [c5adfe1]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/types@17.0.0-rc.4
+  - @objectstack/core@17.0.0-rc.4
+  - @objectstack/observability@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Minor Changes
diff --git a/packages/plugins/plugin-hono-server/package.json b/packages/plugins/plugin-hono-server/package.json
index 2ed888a8d7..2c827a1fca 100644
--- a/packages/plugins/plugin-hono-server/package.json
+++ b/packages/plugins/plugin-hono-server/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/plugin-hono-server",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "Standard Hono Server Adapter for ObjectStack Runtime",
   "main": "dist/index.js",
diff --git a/packages/plugins/plugin-pinyin-search/CHANGELOG.md b/packages/plugins/plugin-pinyin-search/CHANGELOG.md
index 1180609020..6e0a810d4c 100644
--- a/packages/plugins/plugin-pinyin-search/CHANGELOG.md
+++ b/packages/plugins/plugin-pinyin-search/CHANGELOG.md
@@ -1,5 +1,60 @@
 # @objectstack/plugin-pinyin-search
 
+## 17.0.0-rc.4
+
+### Patch Changes
+
+- Updated dependencies [28ad90e]
+- Updated dependencies [64cd010]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [c497d26]
+- Updated dependencies [bbdbf28]
+- Updated dependencies [3905c00]
+- Updated dependencies [4335497]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [b746aa0]
+- Updated dependencies [d8f65fe]
+- Updated dependencies [58ffcab]
+- Updated dependencies [eda599e]
+- Updated dependencies [2b63a00]
+- Updated dependencies [afa6aa5]
+- Updated dependencies [afb83d3]
+- Updated dependencies [c7406b0]
+- Updated dependencies [08f93bc]
+- Updated dependencies [eb3e650]
+- Updated dependencies [290d944]
+- Updated dependencies [02dc076]
+- Updated dependencies [7f1a635]
+- Updated dependencies [5d3ced9]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [1eadac0]
+- Updated dependencies [7c2f7dd]
+- Updated dependencies [9b26699]
+- Updated dependencies [46365ab]
+- Updated dependencies [1c625ca]
+- Updated dependencies [c5adfe1]
+- Updated dependencies [1cae606]
+- Updated dependencies [b9cc17d]
+- Updated dependencies [0d24078]
+- Updated dependencies [5b8f95b]
+- Updated dependencies [2ddba89]
+- Updated dependencies [37a8f2b]
+- Updated dependencies [441d79f]
+- Updated dependencies [2680cd3]
+- Updated dependencies [db2ea82]
+- Updated dependencies [51a587d]
+- Updated dependencies [23dba62]
+- Updated dependencies [d56bcdb]
+- Updated dependencies [488b66c]
+- Updated dependencies [946a131]
+- Updated dependencies [909895d]
+- Updated dependencies [2b52bc8]
+  - @objectstack/types@17.0.0-rc.4
+  - @objectstack/core@17.0.0-rc.4
+  - @objectstack/objectql@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Patch Changes
diff --git a/packages/plugins/plugin-pinyin-search/package.json b/packages/plugins/plugin-pinyin-search/package.json
index 0a637060bb..cb24410afb 100644
--- a/packages/plugins/plugin-pinyin-search/package.json
+++ b/packages/plugins/plugin-pinyin-search/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/plugin-pinyin-search",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "Pinyin search recall for ObjectStack — populates the hidden `__search` companion column (full pinyin + initials of the display/name field) so `$search` hits CJK names typed as pinyin. Locale-gated via OS_SEARCH_PINYIN_ENABLED (#2486).",
   "main": "dist/index.js",
diff --git a/packages/plugins/plugin-reports/CHANGELOG.md b/packages/plugins/plugin-reports/CHANGELOG.md
index f7ad1fdd19..3950c9f3bb 100644
--- a/packages/plugins/plugin-reports/CHANGELOG.md
+++ b/packages/plugins/plugin-reports/CHANGELOG.md
@@ -1,5 +1,138 @@
 # @objectstack/plugin-reports
 
+## 17.0.0-rc.4
+
+### Patch Changes
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [b746aa0]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [d9971d3]
+- Updated dependencies [eb3e650]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [e98fb14]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [1b9a53b]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [46365ab]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [c5adfe1]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [f104bab]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/core@17.0.0-rc.4
+  - @objectstack/platform-objects@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Patch Changes
diff --git a/packages/plugins/plugin-reports/package.json b/packages/plugins/plugin-reports/package.json
index b4c658aef2..ee8897d1b2 100644
--- a/packages/plugins/plugin-reports/package.json
+++ b/packages/plugins/plugin-reports/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/plugin-reports",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "Saved reports + scheduled email digests for ObjectStack — sys_saved_report + sys_report_schedule + IReportService.",
   "main": "dist/index.js",
diff --git a/packages/plugins/plugin-security/CHANGELOG.md b/packages/plugins/plugin-security/CHANGELOG.md
index 7b64d7707c..373f89e413 100644
--- a/packages/plugins/plugin-security/CHANGELOG.md
+++ b/packages/plugins/plugin-security/CHANGELOG.md
@@ -1,5 +1,429 @@
 # @objectstack/plugin-security
 
+## 17.0.0-rc.4
+
+### Patch Changes
+
+- 846ed1f: fix(security): `controlled_by_parent` 现在真的跟随主档访问 —— 折入主档的归属与共享授权 (#5386)
+
+  **这是一次安全收紧。** 升级后,此前被越权看到 / 写到的明细行会读不到、写不了 —— 那正是
+  声明本来就要求的边界。
+
+  ADR-0055 的 `controlled_by_parent` 对作者的承诺是「子记录跟随父记录的访问」。实现只兑现了
+  一半:派生用的主档 id 集来自 `computeRlsFilter(master, 'find')`,即只有 Layer 0(租户)与
+  Layer 1(`rowLevelSecurity` 策略)。归属(owner scope)与 `sys_record_share` 授权由**另一个
+  插件** `plugin-sharing` 的 `buildReadFilter` 贡献,而它对「有效共享模型不是 `private`」的对象
+  返回 `null` —— `controlled_by_parent` 在那边恰好映射为 `public`。于是记录级访问的两半在派生
+  对象上从未相遇。
+
+  后果比文档里那句「sharing grants 未折入」读起来严重得多:
+
+  - 主档上**没有写任何 `rowLevelSecurity`** 的应用,得到的是一个**不受限的主档 id 集**,派生
+    过滤器等于什么都没收窄 —— 只要持有对象级 read,全部明细行可读。行项目类对象(报价行、
+    发票行)是这个形状的常客,而它们携带逐行定价与折扣。
+  - 在主档上补写 RLS 也不是绕法:RLS 与 sharing 过滤器是 **AND**,补写会连同被共享进来的行
+    一起切掉。
+  - 写这半有同样的洞,而且是从另一侧来的:`assertControlledByParentWrite` 只在主档的写 RLS
+    编译出非空过滤器时才检查主档行,主档没写 RLS 时**整段跳过** —— 持有 `allowEdit` 的调用者
+    可以改自己根本看不到的父记录下的明细。
+
+  **修复**:主档可达性改走与「直接读 / 直接写主档」完全相同的路径,复用既有合成点,不在
+  plugin-security 里重刻一份 sharing 语义。
+
+  - 读:`computeControlledByParentFilter` 现在把主档的读 RLS 与 `resolveSharingReadFilter`
+    (`getReadFilter` 已经在用的那个 OWD/共享半边)AND 起来再解析主档 id 集。哪一半生效由
+    **主档自己的有效共享模型**决定,因此派生出的可见集与直接 find 主档逐点一致。
+  - 写:`assertControlledByParentWrite` 在原有的 CRUD `update` + 写 RLS 之外,**无条件**追问
+    plugin-sharing 的单记录写闸 `canEdit`(归属按写深度放宽、`edit` 级共享、
+    `modifyAllRecords` 旁路)—— 无条件,正因为写 RLS 那一半在常见情形下会被整段跳过。
+  - 两侧解析失败一律**fail closed**(主档 id 集为空 / 拒绝写),而不是悄悄放宽回全员可见。
+
+  未变更的部分:v1 的**单层**语义 —— 主档自身的 `controlled_by_parent` 仍不递归下钻;没有装
+  `plugin-sharing` 的部署行为不变(那种部署里主档本身也没有归属与共享可言,派生集依旧与直接
+  读主档相等);`read` 级共享仍然只开读不开写,与直接访问主档的逐动词答案一致。
+
+- 9ce0ca9: **An admin-authored capability's `label`/`description` survive the boot (#5876).**
+
+  `bootstrapSystemCapabilities` seeds `sys_capability` in two halves: the CURATED
+  platform capabilities, and the back-compat DERIVED defaults — one row per
+  capability string a bootstrap permission set grants via `systemPermissions[]`
+  that nothing declared. Its seed loop refreshed `label`/`description` on whatever
+  row it found for a name, without looking at `managed_by`, while the comment
+  directly above it claimed the opposite ("do NOT clobber admin edits"). What
+  #2909 T3 actually made seed-once is `scope`, and only `scope`.
+
+  For a derived name there is no authored copy to reconcile: `label` is
+  `humanize(name)` and `description` is `Capability <name>.`, both generated from
+  the granted string. So an existing row's authored display fields were rewritten
+  to a humanized placeholder on **every boot**, whoever wrote them — silent data
+  loss, invisible from the outside.
+
+  Reachable, narrowly, and it needs the admin row to pre-exist the grant: an admin
+  creates capability `X` in Setup (`managed_by:'admin'` — the only provenance the
+  ADR-0066 write-guard leaves admin-writable), an app whose bootstrap permission
+  set grants `X` is installed, and every boot from then on renames it. The reverse
+  order is not reachable: once the derivation has created the
+  `managed_by:'platform'` placeholder, the write-guard stops the admin editing it
+  at all.
+
+  **The derived half now reconciles display fields only on rows it owns** —
+  `managed_by:'platform'` on a non-curated name, which can only be its own
+  placeholder from an earlier boot. `admin` rows, `package` rows and rows whose
+  provenance is missing are left exactly as their author wrote them, and counted
+  in the new `skippedAuthored` field of the seeding result (reported in the boot
+  summary, not warned about: nothing is degraded, the capability resolves and the
+  authored copy is the better one).
+
+  **The curated half is unchanged.** Those definitions are authored by the
+  platform and a new version legitimately ships new copy, so a curated name still
+  refreshes the row it finds. `scope` stays seed-once on both halves.
+
+  No migration and no authoring change: a placeholder that was already
+  overwritten is not restored (the previous text is gone), but it stops being
+  overwritten again, and an admin's re-edit now sticks.
+
+- d97f2a2: fix(plugin-security): `getReadFilter` applies the `controlled_by_parent` derivation — the analytics read scope was missing the master half entirely
+
+  `getReadFilter` is the read-scope provider bound by the analytics / raw-SQL
+  path: the one read surface that bypasses the engine and therefore has no other
+  source of scope. Its contract is that it returns **the same filter the engine
+  middleware ANDs into every find**. That middleware injects three things — the
+  RLS filter, the ADR-0055 `controlled_by_parent` derivation (`masterFK IN
+(accessible master ids)`), and plugin-sharing's OWD / record-share filter.
+  `getReadFilter` composed only the first and third; `computeControlledByParentFilter`
+  was never called on that path at all.
+
+  For an object whose `sharingModel` is `controlled_by_parent` that is not a
+  partial gap but a total one, because the two layers it _did_ compose both stand
+  down on exactly that object by design: such an object carries no authored RLS
+  (the whole point of the model is that access is derived rather than authored),
+  and it maps to `public` in plugin-sharing's `effectiveSharingModel`, so
+  `buildReadFilter` returns `null`. Both halves returned `null`, the composition
+  returned `undefined`, and the analytics path ran with **no predicate**. A caller
+  who could not read a single master row through `/data` could still `COUNT(*)`
+  and `GROUP BY` its detail rows through `/analytics` — and line-item objects are
+  the usual shape here, so the grouped values are per-line prices and discounts.
+
+  The derivation is now composed into the same AND on that path, resolved from the
+  permission sets `getReadFilter` had already resolved (no second resolution), so
+  the two read surfaces enforce identical scoping — which is why
+  `computeControlledByParentFilter` was extracted and shared in the first place.
+  Failures deny: the derivation is internally fail-closed, and a throw propagates
+  to the method's existing fail-closed handler rather than widening the read. The
+  delegated (`onBehalfOf`) branch already denied outright on this path (#2852) and
+  is unchanged.
+
+  This is the same failure shape #4467 fixed for the OWD/sharing layer of this
+  method, one layer over; #5386 fixed _which inputs_ the derivation folds in, not
+  _whether it runs_ on this surface.
+
+  **Impact.** A deployment with `controlled_by_parent` objects and an analytics /
+  raw-SQL consumer will see those queries return fewer rows — the rows the caller
+  was never entitled to aggregate. No authoring change is required.
+
+- dc6abfd: fix(plugin-security): 被拒收的 capability 声明不再连派生占位一起压掉 (#4967 Part 1/3)
+
+  `SecurityPlugin` 分两遍种 `sys_capability`:第一遍落包声明的 capability
+  (`managed_by:'package'` + `package_id`),第二遍种平台 curated 集合 + 从
+  permission set 的 `systemPermissions[]` **派生**的 back-compat 占位,并**跳过**
+  第一遍报上来的名字,以免占位把已写好的声明覆盖掉。
+
+  问题在于第一遍报的是「读到的每个名字」,而不是「真正落了行的名字」:
+  `bootstrapDeclaredCapabilities` 在 upsert 作出任何决定**之前**就把
+  `cap.name` 推进了返回列表。而 upsert 有三条**拒收**路径,一行都不写。其中
+  「声明没有归属包」这一条既没写行、又占住了名字,于是派生占位也被跳过——
+  capability **在任何一行里都不存在**。净效果是:**写下这条声明,比不写还糟**
+  (不写至少还有派生占位)。这正是 showcase 的
+  `showcase.export_data` 只留下一条 `warn` 的成因。
+
+  修法是把「上报」与「读到」拆开:一个名字进入上报列表(现更名为
+  `materializedNames`)的条件,是本遍**确认它有行**——本遍写成了
+  (seeded / updated / claimed),或找到一行不能被覆盖的既有行(admin 自建、他包
+  所有、curated 平台名)。三条拒收路径按「派生是否会覆盖既有 authored 行」分别
+  处置,理由写在代码里:
+
+  - **curated 平台名**:仍然上报。curated 那一遍无条件种这些名字,行必然存在;
+    且派生路径本来就够不到 curated 名(它已在 curated 表里)。
+  - **他包所有 / admin 自建**:仍然上报。行存在且 label/description 是**作者写
+    的**,派生会把它们刷成 humanize 出来的占位——压掉派生正是这份列表的用途。
+  - **没有归属包**:仅当已存在一行时才上报。没有行时回落到派生占位,和「从未
+    写过这条声明」时一样。
+
+  同时补上这条路径此前缺失的计数器 `skippedUnowned`,于是每条具名声明恰好落在
+  一个计数器里,列表与计数器可以对账。
+
+  **行为变化(升级须知)**:一条被拒收(无归属包)且被某个 permission set 授权
+  的 capability,此前在 `sys_capability` 里**没有任何行**,现在会出现一行
+  `managed_by:'platform'` 的派生占位——即它在 Setup 的能力列表里可见、可解析、
+  带 humanize 出来的 label。注意这不改变**运行时判定**:权限求值一直是按
+  `systemPermissions[]` 里的字符串取并集的,从不查 `sys_capability`;恢复的是
+  注册表一侧的 declared = enforced(能力有定义记录、可见、可管理、有 provenance),
+  不是把一个原本不生效的授权变成生效。若某个部署依赖「那条能力在能力列表里查不
+  到」,升级后它会出现。
+
+  诊断消息同时按 #4632 改进(级别仍为 `warn` —— 功能性降级,非持久性失败):
+  拒收时点名**授权它的 permission set**,并写明真实后果,例如
+  `[security] declared capability "showcase.export_data" has no owning package (granted by showcase_ops): falls back to the back-compat derived placeholder …`。
+  无人授权、或已有行的情形各有对应措辞。
+
+- bf1edef: feat(formula,lint): wire ADR-0056 D4's RLS authoring gate, from the runtime's own predicate (#4983)
+
+  `isSupportedRlsExpression` has carried the same docblock since ADR-0056 D4:
+  "exposed so an authoring-time gate (`objectstack compile`) can REJECT a
+  predicate the runtime would silently drop … A `false` here means 'this
+  predicate will never enforce'." It had **no non-test consumer anywhere** — the
+  function written to fix declared-but-never-read was itself declared and never
+  read. This lands the consumer, in two steps that had to happen in this order.
+
+  **1. `sqlPredicateToCel` and `isSupportedRlsExpression` move FROM
+  `@objectstack/plugin-security` (`src/rls-compiler.ts`) TO `@objectstack/formula`
+  (`src/rls-predicate.ts`), and are exported from its root.** Executable code
+  unchanged — a change of address, not of behaviour; `plugin-security` now imports
+  them from `@objectstack/formula` and keeps no copy, so there is still exactly
+  one definition. No import path outside the two packages changes: neither symbol
+  was ever exported from `@objectstack/plugin-security`'s entry point. The move is
+  what makes step 2 possible at all — `@objectstack/lint` may depend on
+  `@objectstack/spec` and never on a runtime, so with the predicate living in a
+  runtime the gate's only other door was copying the SQL→CEL bridge, whose
+  boundary conditions (quoted literals are never rewritten; canonical CEL passes
+  through unchanged) _are_ the gate's red/green line. A fork drifting by one
+  character rejects policies the runtime executes correctly — the false-positive
+  direction, which is worse than the gap. ADR-0058 D1 asks for a single canonical
+  shape gate; the bridge is part of that gate.
+
+  **2. New `@objectstack/lint` rule `validateRlsPredicateEnforceability`,
+  `error`, on all three authoring commands**, over
+  `permissions[].rowLevelSecurity[].using` and `.check`:
+
+  - **`rls-predicate-unenforceable`** — parses as CEL, outside the pushdown
+    subset: a function call (`size(...)`, `has(...)`), arithmetic, a ternary, a
+    cross-object path (`record.account.region`).
+  - **`rls-predicate-unparseable`** — does not parse as CEL even after the legacy
+    SQL bridge (`=` → `==`, `IN` → `in`): SQL `AND` / `OR` / `LIKE`, a subquery.
+    Its own id because the fix is different — write CEL (`&&`, `||`), not a
+    different shape.
+
+  What the gate prevents, measured through `plugin-security` rather than inferred:
+  `RLSCompiler` drops the policy and logs one request-time WARN. On the read path,
+  when it is the only applicable policy, `compileFilter` returns the
+  `RLS_DENY_FILTER` sentinel instead, which is AND-ed onto the where clause — so
+  every select / update / delete on the object matches **zero rows**. On the
+  ADR-0058 D4 write path the post-image `check` becomes that same sentinel, which
+  no record satisfies, so every insert / update fails with `PermissionDeniedError`.
+  The runtime fails closed, which is why this was survivable: the result is not a
+  hole but a policy that reads as an authorization and behaves as a blanket
+  refusal, with nothing at authoring time pointing at the line that caused it.
+
+  Fix a flagged predicate by rewriting it inside the lowerable subset — `==` `!=`
+  `>` `<` `>=` `<=`, `in`, `&&` `||` `!`, `== null` / `!= null`, and
+  `startsWith` / `endsWith` / `contains` over single-column field paths (ADR-0058
+  D2), against a literal or a `current_user.*` value. Two specific migrations:
+  `has(x)` / `size(x) > 0` → `x != null` (a function call is correct in an object
+  _validation_ rule, which is interpreted, and wrong here, where the predicate is
+  compiled to a filter); and a related record's field → denormalise it onto this
+  object (formula/rollup) and test that column, since RLS cannot join (ADR-0055).
+
+  Same construction as the sharing-rule gate (#4698): the rule does not model the
+  consumer or grep for it — it calls `isSupportedRlsExpression`, the exact
+  function `RLSCompiler.compileFilter` consults to decide whether a dropped policy
+  earns its warning, so the two verdicts are one boolean by construction, pinned
+  in both directions over a shared corpus. Measured before shipping: every RLS
+  predicate declared anywhere in this repo — the `plugin-security` platform seeds,
+  the examples, the dogfood fixtures, the authoring skill — is supported, so the
+  gate turns nothing red that works today. Unlike the sharing-rule gate, CEL
+  _syntax_ is reported here rather than deferred to `expression-invalid`:
+  `validateStackExpressions` does not walk `rowLevelSecurity` at all, and could not
+  judge this field correctly if it did, because `owner_id = current_user.id` is a
+  CEL syntax error and a working RLS predicate at the same time.
+
+- 69a89ce: fix(plugin-security,plugin-sharing): the write path consults the View/Modify All Data bypass — one predicate for `security/explain` and `/data` (#4647)
+
+  A **Modify All Data** holder, a `sharingModel: 'private'` object, and a record
+  whose `owner_id` is NULL got two opposite answers for one
+  (principal, record, operation) triple:
+
+  ```
+  POST /api/v1/security/explain  { object, operation: 'update', recordId }
+    → allowed: true, layers[vama_bypass]: "View/Modify All Data bypass held
+      via [admin_full_access] — ownership and sharing checks are skipped"
+  PATCH /api/v1/data/crm_contract/<id>
+    → 403 FORBIDDEN
+  ```
+
+  Filling `owner_id` in made the same PATCH succeed, so the write path really was
+  running the record-level ownership check the bypass layer said had been skipped.
+  `sys_attachment`'s `canEdit(parent)` gate agreed with the 403, not with explain.
+  Ownerless rows are not exotic: a system-context seed writes them by design (the
+  seed loader disables `owner_id` injection).
+
+  **The write path was the side that was wrong.** Modify All Data means an admin
+  edits any record regardless of ownership (the Salesforce reference frame this
+  platform's `modifyAllRecords` already follows, #1883), so:
+
+  - `SharingService.canEdit` / `canDelete` now consult the super-user write bypass
+    **after** ownership and shares have failed, through the existing late-bound
+    `ISecurityService.hasWriteBypass` probe. The `sys_attachment`
+    `canEdit(parent)` gate and the sharing-rule management gate reach the same
+    answer because they call the same function.
+  - The bypass they consult and the one `security/explain` reports are now **one
+    predicate** — `PermissionEvaluator.superuserBypassSets` — rather than two
+    independent readings of the permission sets. A cross-path test pins the triple
+    through both `explain` and the real write middleware chain and asserts they
+    agree, for update, delete and the attachment gate.
+
+  **The widening is exactly Modify-scoped.** `viewAllRecords` ("View All Data") is
+  a read power and never grants write: explain's `vama_bypass` layer is now
+  operation-aware, asking for the modify bit on a write and the view bit on a read,
+  and a view-only holder is refused on both paths. The probe still fails **closed**
+  — no `@objectstack/plugin-security`, a throwing probe, a principal-less or
+  on-behalf-of context all degrade to owner-only.
+
+  **Explain payload self-consistency.** For a record-grained request the top-level
+  `allowed` and the `record` verdict no longer contradict each other on this
+  triple: the row is `visible: true` with `decidedBy: 'vama_bypass'`, the
+  `vama_bypass` layer carries its own per-record attribution, and the `sharing`
+  layer credits the bypass instead of reporting "no ownership and no edit/full
+  share grants write" next to `allowed: true`. Where the bypass is not what
+  admitted the row (owner, or an admitting share) the previous `decidedBy` is
+  unchanged. Note that for a principal with **no** bypass, an object-level
+  `allowed: true` beside `record.visible: false` remains correct and intended —
+  `allowed` answers the object question, `record` answers the row question, and it
+  is the `record` verdict that the write path mirrors.
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [b746aa0]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [0f17114]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [58f3220]
+- Updated dependencies [07f1822]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [d9971d3]
+- Updated dependencies [eb3e650]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [e98fb14]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [1b9a53b]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [46365ab]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [c5adfe1]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [bf1edef]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [f104bab]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/core@17.0.0-rc.4
+  - @objectstack/platform-objects@17.0.0-rc.4
+  - @objectstack/formula@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Minor Changes
diff --git a/packages/plugins/plugin-security/package.json b/packages/plugins/plugin-security/package.json
index d5c532c8b7..33a0d05bff 100644
--- a/packages/plugins/plugin-security/package.json
+++ b/packages/plugins/plugin-security/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/plugin-security",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "Security Plugin for ObjectStack — RBAC, RLS, and Field-Level Security Runtime",
   "main": "dist/index.js",
diff --git a/packages/plugins/plugin-sharing/CHANGELOG.md b/packages/plugins/plugin-sharing/CHANGELOG.md
index 5daab65ad7..6bf5cdf163 100644
--- a/packages/plugins/plugin-sharing/CHANGELOG.md
+++ b/packages/plugins/plugin-sharing/CHANGELOG.md
@@ -1,5 +1,448 @@
 # @objectstack/plugin-sharing
 
+## 17.0.0-rc.4
+
+### Patch Changes
+
+- 7f955e5: fix(sharing): deleting a record now revokes every `sys_record_share` row on it, whatever the source (#5103)
+
+  A share row says "principal P has level L on (object O, record R)". Delete R and
+  the row describes nothing — yet until now it stayed in the table forever.
+
+  #4779 (PR #5102) bound an `afterDelete` for this, but inside the sharing-RULE
+  package, where two conditions fenced it in: it revokes only `source: 'rule'`
+  rows, and it binds only on objects that appear in `sys_sharing_rule`. So an
+  object that uses nothing but MANUAL shares — a `sharingModel: 'private'` object
+  with no rule ever configured — had no delete hook at all, and **manual share +
+  record delete = a permanent orphan**.
+
+  Today the harm is bounded, and only because record ids are never reused: the
+  `record_id IN (…)` predicate `buildReadFilter` emits matches nothing. Nothing
+  enforces that assumption. A custom primary key, an import that preserves ids, or
+  any future id recycling turns every one of those rows into a real privilege
+  escalation — a new record landing on a recycled id inherits the dead record's
+  recipients outright. Secondarily, `sys_record_share` grew without bound and
+  Setup's Record Shares list showed rows pointing at nothing.
+
+  **What changed**
+
+  - **A record-delete cascade on every sharing-capable object.** `plugin-sharing`
+    binds one `beforeDelete`/`afterDelete` pair with no object filter and judges
+    the object's sharing posture from its `sharingModel` metadata _per delete_.
+    Nothing is enumerated at boot, so nothing goes stale: an object that gains
+    `sharingModel` at runtime is covered on its very next delete, with no rebind.
+    Bounded deletes (a scalar id, an `$in` list, or a predicate matching at most
+    1000 rows) are revoked synchronously and set-based; an unbounded one queues an
+    object-scoped orphan sweep instead. System-context deletes cascade too.
+  - **A boot-time orphan sweep keyed on record existence.** On
+    `kernel:bootstrapped`, share rows whose RECORD no longer exists are revoked —
+    historical orphans, rows a failed hook missed, and the one posture the cascade
+    deliberately skips (an unmarked system object). This is a different question
+    from the existing `sweepOrphanedRuleGrants`, which asks whether the RULE row
+    still exists and therefore can never see a manual share. Bounded per boot:
+    keyset pages, one batched existence probe per object per page, and a scan cap
+    that reports when it stopped early. An object whose existence probe FAILS has
+    its rows left in place — "could not ask" is never read as "the record is gone".
+
+  **What did not change**
+
+  Rule _recompute_ still never touches a manual share. That boundary (#5102) is
+  the point: while the record exists, a manual grant is a human decision no rule
+  evaluation may overrule. Only the record's DELETION revokes it, and only because
+  there is no longer anything to have access to.
+
+  New exports for hosts that compose the plugin by hand:
+  `bindRecordShareCascade` / `unbindRecordShareCascade`,
+  `objectCanCarryRecordShares`, `SharingService.revokeSharesForDeletedRecords`,
+  `SharingService.sweepOrphanedRecordShares`, and `effectiveSharingModel`. Nothing
+  was removed or renamed; the standard `SharingServicePlugin` composition needs no
+  changes.
+
+- 6e66cbe: fix(plugin-sharing): a deleted record kills its share links — resolve fails closed, and the delete cascades (#5190)
+
+  `ShareLinkService.resolveToken` checked the token, `revoked_at`, `expires_at`,
+  the audience and the password — **but never whether the record the link points
+  at still exists**. Nothing revoked links on delete either: #5103's cascade
+  covers `sys_record_share` only. So a share link outlived its record, kept
+  resolving, and kept stamping `use_count` / `last_used_at`.
+
+  That is worse than the `sys_record_share` orphan #5103 fixed, and for a
+  structural reason: a share row names its beneficiaries, while a share link is an
+  identity-less **capability token** — holding the URL _is_ the authorisation. The
+  moment a record id is reused (custom primary keys, an import that preserves ids,
+  any future id recycling) a link that morally died with its record starts
+  authorising a brand-new record, for whoever kept it.
+
+  Both halves of the fix ship together, and the first does not depend on the
+  second having run:
+
+  - **`resolveToken` re-asks whether the record exists**, and returns `null`
+    through the _same_ branch as revoked / expired — no distinct code, no distinct
+    error, nothing an unauthorised holder can read "that record was deleted" out
+    of. The probe sits after the cheap in-memory gates (a revoked link still costs
+    no query) and _before_ the usage stamp, so a dead record no longer ticks
+    `use_count` / `last_used_at`. It fails **closed**: a probe that throws denies,
+    because "cannot ask" must not authorise.
+  - **Record deletes now cascade to `sys_share_link`**, on #5103's existing seam
+    rather than a parallel one — the same global `beforeDelete` row-set stash, the
+    same `afterDelete` set-based revoke, the same serialized sweep queue for
+    unbounded deletes, and the same `kernel:bootstrapped` orphan sweep (keyset
+    pages, a scan cap that reports itself, one batched existence probe per object
+    per page, and rows left strictly alone when that probe fails). The two halves
+    are isolated, so a driver error reclaiming grants cannot also skip the tokens.
+
+  The link half judges posture from `publicSharing`, which is _independent_ of
+  `sharingModel`: the object most likely to hold links is a platform object that
+  opted into link sharing, and that is exactly the object the record-share
+  predicate skips. `publicSharing` declared counts even when it is currently
+  `enabled: false` — links minted while it was on outlive the flip.
+
+  An orphaned link row is **deleted**, not stamped `revoked_at`: its subject is
+  gone, so there is no live link left to keep a revocation record of, and the
+  table would otherwise only grow (with Setup's link lists pointing at records
+  that no longer exist). Links an admin revokes keep their audit row exactly as
+  before.
+
+  No metadata, spec or API shape changes. Deployments see fewer rows in
+  `sys_share_link` after the next boot, and links whose record was already deleted
+  stop resolving immediately — which is the point.
+
+- f226605: fix(plugin-sharing): hierarchy resolver 拿到调用方真实的活动组织(权威 `organizationId`)(#5859)
+
+  `resolveOwnerScopeIds` 构造 `HierarchyScopeContext` 时读的是
+  `(context as any).organizationId` —— **仓内没有任何传输层写过这个键**。REST
+  (`rest-server.ts`)和 runtime dispatcher(`resolve-execution-context.ts`)都从同一个
+  授权解析器 `resolveAuthzContext` 组装执行上下文,活动组织落在 `tenantId`
+  (session 路径 = `session.activeOrganizationId`,API-key 路径 = `sys_api_key.organization_id`),
+  `ExecutionContext` 的字段注释写的也正是这句。所以这个读取**结构性恒为 `null`**:
+  自 ADR-0057 以来,每一次 DEPTH(`unit` / `unit_and_below` / `own_and_reports`)解析
+  都是在**没有组织约束**的前提下跑的,而企业版 resolver 只按 `organizationId` 收窄
+  自己的 owner 集合 —— 于是整条 DEPTH 租户隔离从未生效。
+
+  爆炸半径不止「共享管理」一路:同一个 owner 集合喂给 `matchesOwnerScope` →
+  `canEdit` / `canDelete`,以及批量写路径 `buildWriteFilter`。#5852 的实测里,
+  `group` 姿态下的普通成员对**兄弟组织**记录 `POST /data/:obj/:idB/shares` 得到
+  **201**;探针那个 app 的写路径另被 `member_default` 的 `owner_only_writes`
+  (keyed on `created_by`)挡下,所以只观测到共享管理一路 —— **不带这条 owner-only
+  RLS 的部署,跨组织 edit/delete 同样放行**。
+
+  本次修复(producer 半边,契约半边见 #5858 / PR #5973):
+
+  - 权威字段 `organizationId` 由执行上下文的活动组织填充;`tenantId` 作为
+    `@deprecated` 兼容别名原样继续携带(不是消费端 `?? tenantId` 兜底 —— 那正是
+    #5858 为 resolver 明令排除的宽容消费者形状)。同样的映射在
+    `@objectstack/plugin-security` 的 Layer-0 租户墙里早已在用
+    (`computeTenantLayer0Filter({ organizationId: context?.tenantId })`),两层
+    enforcement 现在按同一个字段的同一个值收窄。
+  - 无活动组织时如实传 `null`(契约类型即 `string | null`),空白字符串归一为
+    `null`,绝不让一个假的组织 id 混进 resolver 的查询与日志。
+  - resolver 抛错的静默回退改为**留声**(`logger.warn`):此前「resolver 炸了」和
+    「层级里确实没有别人」在外部完全同形,这也是本缺陷长期不可见的原因之一。
+
+  ## 姿态感知的组织门(user-visible 行为变化)
+
+  `SharingService` 新增一个 late-bound 的 `tenancy` 姿态探针(读法与 `SecurityPlugin`
+  为 Layer-0 墙读 `tenancy` 服务的完全一致,由 `SharingServicePlugin` 自动接线),
+  按 **ADR-0105 D1** 的既有分叉决定「没有活动组织」意味着什么 —— 与
+  `computeTenantLayer0Filter` 对同一问题给出的答案逐条同形:
+
+  - **`single`**(纯单租户,无组织):**行为不变**,DEPTH 照常 widened。此处「没有组织」
+    是那一个隐含租户,不是「所有组织」。
+  - **`group` / `isolated`**(有墙):权威组织缺失/空白 → **拒绝**,根本不咨询 resolver,
+    回落 owner-only 并打一条点名 ADR-0095 D1 / ADR-0105 D1 与 #5973 契约义务的 `warn`。
+    即:有墙部署里,缺组织的 owner-scope 解析从「按无租户约束展开」变为「拒绝展开」。
+  - **姿态解析不出**(未接线 / 探针抛错 / 词表外的值)→ 按**有墙**处理。未知姿态不是
+    `single` 的证据,否则恰恰在配置已经可疑的部署上恢复了展开。
+
+  对已有部署的影响:`single` 部署零变化;`group` / `isolated` 部署中,一个**没有活动
+  组织**的调用方将不再通过 DEPTH 拿到跨组织的 owner 集合(共享管理 / edit / delete /
+  批量写四条路径同时闭合)。
+
+- c272e48: fix(plugin-sharing): recompute sharing rules for predicate (`multi`) writes — stale `sys_record_share` grants no longer survive a bulk update (#4779)
+
+  `bindRuleHooks` located the rows to recompute from a single record id:
+
+  ```ts
+  const id = String(data?.id ?? ctx?.input?.id ?? "");
+  if (!id) return;
+  ```
+
+  `ObjectQL.update()` only populates `input.id` when `where.id` is a scalar. A
+  predicate write (`multi: true`) routes to `updateMany`, leaves `input.id`
+  undefined, and carries no id in its payload — so **every bulk write skipped
+  sharing-rule recompute entirely**.
+
+  The consequence is a fail-open on the authorization side. A criteria-based rule
+  materialises `sys_record_share` rows; an admin then bulk-updates those records
+  out of the criteria (`{ where: { region: 'east' }, multi: true, data: { region:
+'west' } }`); nothing recomputes, the grant rows stay in the table, and the
+  recipients keep the read/edit access the rule no longer implies. Same family as
+  #4757 (`sys_attachment`) and #4778 (approval locks), but better hidden — a stale
+  grant is indistinguishable from a legitimate one. The reverse direction (bulk
+  update **into** a rule's criteria never granting) was broken too.
+
+  **What changes**
+
+  The hooks now key off the write's ROW SET instead of one id. `beforeUpdate` /
+  `beforeDelete` resolve the affected rows from the predicate and stash them on
+  the shared hook context (the `before` hook is where it must happen — the write
+  is what makes those rows unfindable); the `after` hook acts on them:
+
+  - **Bounded set (≤ 1000 rows, `RULE_RECOMPUTE_ROW_CAP`)** — `evaluateAllForRecord`
+    per row, synchronously. Diff-based, so this covers both directions: rows moved
+    out of a rule's criteria are revoked, rows moved in are granted.
+  - **Unbounded set** (over the cap, `multi: true` with no `where` at all, or a
+    resolve that failed) — every `source: 'rule'` grant on the object is revoked
+    **synchronously** in one set-based statement, and the deserved grants are
+    restored **asynchronously** by reconciling the object's rules.
+
+  **The write is never refused.** Refusing would turn an internal recompute bound
+  into a business-visible limit on how many rows an admin may update, reported by
+  a subsystem they never configured. The asymmetry it trades on instead:
+  over-granting is a security incident, under-granting is an availability wobble.
+  So the safety half is always synchronous and complete, and only the expensive
+  restoration half is deferred.
+
+  **Operational note.** After a bulk write whose row set could not be bounded,
+  recipients may briefly lose access to records they still qualify for, until the
+  background re-grant finishes. It is logged with the object and the reason. The
+  re-grant is in-process; if it is lost to a crash, the plugin's existing
+  `kernel:bootstrapped` backfill re-runs the same idempotent reconcile on the next
+  start, and any subsequent `sys_sharing_rule` write reconciles too.
+
+  **Also fixed:** the rule hooks now bind `afterDelete` and retire the deleted
+  records' rule grants. Nothing else could: `evaluateRule` iterates records that
+  still exist, so a grant whose record is gone was unreachable by every reconcile
+  path and outlived restarts. Harmless only while record ids are never reused —
+  an assumption nothing in the platform enforces.
+
+  New on `SharingRuleService`: `revokeRuleGrantsForObject`,
+  `revokeRuleGrantsForRecords` and `evaluateAllRulesForObject`. Manual
+  (`source: 'manual'`) shares are never touched by any of them.
+
+- 69a89ce: fix(plugin-security,plugin-sharing): the write path consults the View/Modify All Data bypass — one predicate for `security/explain` and `/data` (#4647)
+
+  A **Modify All Data** holder, a `sharingModel: 'private'` object, and a record
+  whose `owner_id` is NULL got two opposite answers for one
+  (principal, record, operation) triple:
+
+  ```
+  POST /api/v1/security/explain  { object, operation: 'update', recordId }
+    → allowed: true, layers[vama_bypass]: "View/Modify All Data bypass held
+      via [admin_full_access] — ownership and sharing checks are skipped"
+  PATCH /api/v1/data/crm_contract/<id>
+    → 403 FORBIDDEN
+  ```
+
+  Filling `owner_id` in made the same PATCH succeed, so the write path really was
+  running the record-level ownership check the bypass layer said had been skipped.
+  `sys_attachment`'s `canEdit(parent)` gate agreed with the 403, not with explain.
+  Ownerless rows are not exotic: a system-context seed writes them by design (the
+  seed loader disables `owner_id` injection).
+
+  **The write path was the side that was wrong.** Modify All Data means an admin
+  edits any record regardless of ownership (the Salesforce reference frame this
+  platform's `modifyAllRecords` already follows, #1883), so:
+
+  - `SharingService.canEdit` / `canDelete` now consult the super-user write bypass
+    **after** ownership and shares have failed, through the existing late-bound
+    `ISecurityService.hasWriteBypass` probe. The `sys_attachment`
+    `canEdit(parent)` gate and the sharing-rule management gate reach the same
+    answer because they call the same function.
+  - The bypass they consult and the one `security/explain` reports are now **one
+    predicate** — `PermissionEvaluator.superuserBypassSets` — rather than two
+    independent readings of the permission sets. A cross-path test pins the triple
+    through both `explain` and the real write middleware chain and asserts they
+    agree, for update, delete and the attachment gate.
+
+  **The widening is exactly Modify-scoped.** `viewAllRecords` ("View All Data") is
+  a read power and never grants write: explain's `vama_bypass` layer is now
+  operation-aware, asking for the modify bit on a write and the view bit on a read,
+  and a view-only holder is refused on both paths. The probe still fails **closed**
+  — no `@objectstack/plugin-security`, a throwing probe, a principal-less or
+  on-behalf-of context all degrade to owner-only.
+
+  **Explain payload self-consistency.** For a record-grained request the top-level
+  `allowed` and the `record` verdict no longer contradict each other on this
+  triple: the row is `visible: true` with `decidedBy: 'vama_bypass'`, the
+  `vama_bypass` layer carries its own per-record attribution, and the `sharing`
+  layer credits the bypass instead of reporting "no ownership and no edit/full
+  share grants write" next to `allowed: true`. Where the bypass is not what
+  admitted the row (owner, or an admitting share) the previous `decidedBy` is
+  unchanged. Note that for a principal with **no** bypass, an object-level
+  `allowed: true` beside `record.visible: false` remains correct and intended —
+  `allowed` answers the object question, `record` answers the row question, and it
+  is the `record` verdict that the write path mirrors.
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [64cd010]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [c497d26]
+- Updated dependencies [bbdbf28]
+- Updated dependencies [2e284b2]
+- Updated dependencies [3905c00]
+- Updated dependencies [4335497]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [b746aa0]
+- Updated dependencies [947d4f9]
+- Updated dependencies [d8f65fe]
+- Updated dependencies [58ffcab]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [2b63a00]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [0f17114]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [afa6aa5]
+- Updated dependencies [afb83d3]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [c7406b0]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [58f3220]
+- Updated dependencies [07f1822]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [08f93bc]
+- Updated dependencies [d9971d3]
+- Updated dependencies [eb3e650]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [290d944]
+- Updated dependencies [02dc076]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [e98fb14]
+- Updated dependencies [5d3ced9]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [1b9a53b]
+- Updated dependencies [1eadac0]
+- Updated dependencies [7c2f7dd]
+- Updated dependencies [9b26699]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [46365ab]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [c5adfe1]
+- Updated dependencies [26e1029]
+- Updated dependencies [1cae606]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b9cc17d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [0d24078]
+- Updated dependencies [089767f]
+- Updated dependencies [5b8f95b]
+- Updated dependencies [2ddba89]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [37a8f2b]
+- Updated dependencies [441d79f]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [bf1edef]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [2680cd3]
+- Updated dependencies [c5a5996]
+- Updated dependencies [db2ea82]
+- Updated dependencies [51a587d]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [d56bcdb]
+- Updated dependencies [f104bab]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [488b66c]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [946a131]
+- Updated dependencies [909895d]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+- Updated dependencies [2b52bc8]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/types@17.0.0-rc.4
+  - @objectstack/core@17.0.0-rc.4
+  - @objectstack/platform-objects@17.0.0-rc.4
+  - @objectstack/objectql@17.0.0-rc.4
+  - @objectstack/formula@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Major Changes
diff --git a/packages/plugins/plugin-sharing/package.json b/packages/plugins/plugin-sharing/package.json
index 397038a449..8c699fca73 100644
--- a/packages/plugins/plugin-sharing/package.json
+++ b/packages/plugins/plugin-sharing/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/plugin-sharing",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "Record-level sharing for ObjectStack — sys_record_share + middleware that enforces sharingModel + ISharingService.",
   "main": "dist/index.js",
diff --git a/packages/plugins/plugin-webhooks/CHANGELOG.md b/packages/plugins/plugin-webhooks/CHANGELOG.md
index e3549fa02c..87d49ac352 100644
--- a/packages/plugins/plugin-webhooks/CHANGELOG.md
+++ b/packages/plugins/plugin-webhooks/CHANGELOG.md
@@ -1,5 +1,136 @@
 # @objectstack/plugin-webhooks
 
+## 17.0.0-rc.4
+
+### Patch Changes
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [b746aa0]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [d9971d3]
+- Updated dependencies [eb3e650]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [46365ab]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [c5adfe1]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [9c90ea0]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/core@17.0.0-rc.4
+  - @objectstack/service-messaging@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Minor Changes
diff --git a/packages/plugins/plugin-webhooks/package.json b/packages/plugins/plugin-webhooks/package.json
index 621897c7f5..79519b6c8c 100644
--- a/packages/plugins/plugin-webhooks/package.json
+++ b/packages/plugins/plugin-webhooks/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/plugin-webhooks",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "Persistent, cluster-aware webhook dispatcher. Durable outbox + per-partition cluster.lock for exactly-once-ish delivery across nodes. See content/docs/concepts/webhook-delivery.mdx.",
   "type": "module",
diff --git a/packages/qa/dogfood/CHANGELOG.md b/packages/qa/dogfood/CHANGELOG.md
index 008d689ee3..8ce01999d2 100644
--- a/packages/qa/dogfood/CHANGELOG.md
+++ b/packages/qa/dogfood/CHANGELOG.md
@@ -1,5 +1,253 @@
 # @objectstack/dogfood
 
+## 0.0.40-rc.3
+
+### Patch Changes
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [c637387]
+- Updated dependencies [c113690]
+- Updated dependencies [705efeb]
+- Updated dependencies [978fed2]
+- Updated dependencies [c36abfe]
+- Updated dependencies [9ecdca9]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [1792384]
+- Updated dependencies [2f6516e]
+- Updated dependencies [e6b1bb0]
+- Updated dependencies [a7b854f]
+- Updated dependencies [f56ebea]
+- Updated dependencies [64cd010]
+- Updated dependencies [f522e95]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [628b028]
+- Updated dependencies [b857356]
+- Updated dependencies [fce4c73]
+- Updated dependencies [f6385c7]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [c5e7bd9]
+- Updated dependencies [0162c81]
+- Updated dependencies [055f0c9]
+- Updated dependencies [7a40b7a]
+- Updated dependencies [7cf1531]
+- Updated dependencies [586d6f7]
+- Updated dependencies [2d14b35]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [c497d26]
+- Updated dependencies [bbdbf28]
+- Updated dependencies [93929c2]
+- Updated dependencies [2e284b2]
+- Updated dependencies [3905c00]
+- Updated dependencies [4335497]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [bcfebb0]
+- Updated dependencies [533a0a4]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [846ed1f]
+- Updated dependencies [947d4f9]
+- Updated dependencies [d8f65fe]
+- Updated dependencies [58ffcab]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [3133cda]
+- Updated dependencies [1f0e7cb]
+- Updated dependencies [8dbd2a8]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c794f78]
+- Updated dependencies [9ce0ca9]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [2b63a00]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [9c4f174]
+- Updated dependencies [d25f20b]
+- Updated dependencies [205e81b]
+- Updated dependencies [37e38d1]
+- Updated dependencies [ecc61ab]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [afa6aa5]
+- Updated dependencies [afb83d3]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [2b2175b]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [c7406b0]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [729a43a]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [08f93bc]
+- Updated dependencies [d9971d3]
+- Updated dependencies [d97f2a2]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [290d944]
+- Updated dependencies [02dc076]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [88a6bed]
+- Updated dependencies [a6b3ee7]
+- Updated dependencies [7f1a635]
+- Updated dependencies [e98fb14]
+- Updated dependencies [5d3ced9]
+- Updated dependencies [9fa6bab]
+- Updated dependencies [1b9a53b]
+- Updated dependencies [61dc08e]
+- Updated dependencies [8dcf607]
+- Updated dependencies [b691ba9]
+- Updated dependencies [1eadac0]
+- Updated dependencies [7c2f7dd]
+- Updated dependencies [9b26699]
+- Updated dependencies [95b4f0d]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [e18e3da]
+- Updated dependencies [b508244]
+- Updated dependencies [8597a7d]
+- Updated dependencies [594508e]
+- Updated dependencies [ff39e63]
+- Updated dependencies [1c625ca]
+- Updated dependencies [b5459bc]
+- Updated dependencies [1624f4a]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [26e1029]
+- Updated dependencies [1cae606]
+- Updated dependencies [4addd9d]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b9cc17d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [de113a4]
+- Updated dependencies [db8c285]
+- Updated dependencies [0d24078]
+- Updated dependencies [089767f]
+- Updated dependencies [5b8f95b]
+- Updated dependencies [2ddba89]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [2cca98b]
+- Updated dependencies [07f1822]
+- Updated dependencies [37a8f2b]
+- Updated dependencies [441d79f]
+- Updated dependencies [7f955e5]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [dc6abfd]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [bf1edef]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [2680cd3]
+- Updated dependencies [c5a5996]
+- Updated dependencies [b40f81c]
+- Updated dependencies [6e66cbe]
+- Updated dependencies [f226605]
+- Updated dependencies [c272e48]
+- Updated dependencies [9f41ee6]
+- Updated dependencies [db2ea82]
+- Updated dependencies [51a587d]
+- Updated dependencies [ae490ef]
+- Updated dependencies [9c90ea0]
+- Updated dependencies [41c3b48]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [ef8b1ff]
+- Updated dependencies [1f1edc0]
+- Updated dependencies [718b229]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [d56bcdb]
+- Updated dependencies [f104bab]
+- Updated dependencies [dca25e1]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [488b66c]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [e92e2c3]
+- Updated dependencies [946a131]
+- Updated dependencies [909895d]
+- Updated dependencies [c183a12]
+- Updated dependencies [69a89ce]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+- Updated dependencies [2b52bc8]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/types@17.0.0-rc.4
+  - @objectstack/service-analytics@17.0.0-rc.4
+  - @objectstack/metadata@17.0.0-rc.4
+  - @objectstack/platform-objects@17.0.0-rc.4
+  - @objectstack/plugin-audit@17.0.0-rc.4
+  - @objectstack/plugin-auth@17.0.0-rc.4
+  - @objectstack/objectql@17.0.0-rc.4
+  - @objectstack/example-showcase@0.3.14-rc.3
+  - @objectstack/plugin-email@17.0.0-rc.4
+  - @objectstack/plugin-security@17.0.0-rc.4
+  - @objectstack/verify@17.0.0-rc.4
+  - @objectstack/plugin-sharing@17.0.0-rc.4
+  - @objectstack/mcp@17.0.0-rc.4
+  - @objectstack/service-messaging@17.0.0-rc.4
+  - @objectstack/service-storage@17.0.0-rc.4
+  - @objectstack/example-crm@4.0.92-rc.3
+  - @objectstack/connector-mcp@17.0.0-rc.4
+  - @objectstack/connector-openapi@17.0.0-rc.4
+  - @objectstack/connector-rest@17.0.0-rc.4
+  - @objectstack/plugin-webhooks@17.0.0-rc.4
+
 ## 0.0.40-rc.2
 
 ### Patch Changes
diff --git a/packages/qa/dogfood/package.json b/packages/qa/dogfood/package.json
index 46b4abf781..08284e67c8 100644
--- a/packages/qa/dogfood/package.json
+++ b/packages/qa/dogfood/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/dogfood",
-  "version": "0.0.40-rc.2",
+  "version": "0.0.40-rc.3",
   "private": true,
   "license": "Apache-2.0",
   "description": "Dogfood regression gate — hand-written golden tests that boot real example apps through @objectstack/verify's in-process HTTP stack, pinning historical runtime regressions (#2018 timezone bucketing, #1994 cross-owner RLS, #2004 field fidelity) that static checks miss.",
diff --git a/packages/qa/downstream-contract/CHANGELOG.md b/packages/qa/downstream-contract/CHANGELOG.md
index 9d4d890e23..e642d8083f 100644
--- a/packages/qa/downstream-contract/CHANGELOG.md
+++ b/packages/qa/downstream-contract/CHANGELOG.md
@@ -1,5 +1,126 @@
 # @objectstack/downstream-contract
 
+## 0.0.38-rc.3
+
+### Patch Changes
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [d9971d3]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+
 ## 0.0.38-rc.2
 
 ### Patch Changes
diff --git a/packages/qa/downstream-contract/package.json b/packages/qa/downstream-contract/package.json
index 7cd94453c1..4f7b3b7450 100644
--- a/packages/qa/downstream-contract/package.json
+++ b/packages/qa/downstream-contract/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/downstream-contract",
-  "version": "0.0.38-rc.2",
+  "version": "0.0.38-rc.3",
   "description": "Frozen third-party consumer fixture — a backward-compatibility gate for @objectstack/spec. Authored the way an external project on a published release authors metadata; if a spec change breaks it, that change is breaking (#2035).",
   "license": "Apache-2.0",
   "private": true,
diff --git a/packages/qa/http-conformance/CHANGELOG.md b/packages/qa/http-conformance/CHANGELOG.md
index 9c66a5c866..5c1e4d6c20 100644
--- a/packages/qa/http-conformance/CHANGELOG.md
+++ b/packages/qa/http-conformance/CHANGELOG.md
@@ -1,5 +1,19 @@
 # @objectstack/http-conformance
 
+## 0.0.6-rc.3
+
+### Patch Changes
+
+- Updated dependencies [29c6c9d]
+- Updated dependencies [b746aa0]
+- Updated dependencies [eb3e650]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [46365ab]
+- Updated dependencies [c5adfe1]
+  - @objectstack/core@17.0.0-rc.4
+
 ## 0.0.6-rc.2
 
 ### Patch Changes
diff --git a/packages/qa/http-conformance/package.json b/packages/qa/http-conformance/package.json
index b6dccb4f5a..a65cd2e2dd 100644
--- a/packages/qa/http-conformance/package.json
+++ b/packages/qa/http-conformance/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/http-conformance",
-  "version": "0.0.6-rc.2",
+  "version": "0.0.6-rc.3",
   "private": true,
   "license": "Apache-2.0",
   "description": "HTTP transport-port conformance gate (ADR-0076 D11/OQ#10, #2462) — a zero-dependency node:http reference implementation of IHttpServer plus a cross-adapter suite that boots the dispatcher bridge and REST generator on it AND on plugin-hono-server, pinning that the port stays free of framework-isms. Not published; validation instrument, not a product server.",
diff --git a/packages/rest/CHANGELOG.md b/packages/rest/CHANGELOG.md
index 789319bca5..150e81ce32 100644
--- a/packages/rest/CHANGELOG.md
+++ b/packages/rest/CHANGELOG.md
@@ -1,5 +1,970 @@
 # @objectstack/rest
 
+## 17.0.0-rc.4
+
+### Major Changes
+
+- d9cac60: **BREAKING** — `GET /meta/:type/:name` now answers exactly one body shape: the
+  `GetMetaItemResponseSchema` envelope `{ type, name, item, … }` that
+  `packages/spec` has always declared for it. On the default configuration this
+  endpoint used to answer the **bare metadata document** instead (#5563).
+
+  ### What changed, and why it is breaking
+
+  The route had two mutually exclusive branches with different response
+  structures. The cached branch — reached whenever `metadata.enableCache` is on,
+  which is the **default** (`enableCache: z.boolean().default(true)`) — served
+  `getMetaItemCached`'s `result.data`, and that value has the envelope already
+  stripped. The uncached branch served `getMetaItem`'s envelope. So the one shape
+  the spec declared was the one a default deployment could not obtain, and the
+  envelope surfaced only when the cache was off or when the read structurally
+  bypassed it (`app`, `doc`, `book`, `?state=draft`, `?preview=draft`,
+  `?package=`). Consumers had no correct static type — they sniffed at runtime or
+  reached for `as any` (#5545 was blocked on exactly this).
+
+  The dispatcher's `/meta` domain had the same split one layer down: the protocol
+  resolver answered the envelope while the ObjectQL-registry and MetadataService
+  fallbacks answered bare documents. Both fallbacks now wrap what they found,
+  taking `type`/`name` from the request.
+
+  ### Migration
+
+  `GET /api/v1/meta/object/customer`, default configuration:
+
+  ```jsonc
+  // before — the bare document
+  { "name": "customer", "label": "Customer", "fields": { /* … */ } }
+
+  // after — the declared envelope; the document is verbatim under `item`
+  {
+    "type": "object",
+    "name": "customer",
+    "item": { "name": "customer", "label": "Customer", "fields": { /* … */ } }
+  }
+  ```
+
+  - **Reading the body directly** (`fetch`, `client.meta.getItem`,
+    `client.meta.getCached().data`): read the document at `.item`. Nothing inside
+    it changed. `type` is the canonical singular metadata type name, so
+    `/meta/objects/customer` and `/meta/object/customer` answer the same `type`.
+  - **`useObject` / `useFields` (`@objectstack/client-react`)**: `useObject().data`
+    is now the envelope — `data.item.label`, `data.item.fields`, where it used to
+    be `data.label` / `data.fields`. `useFields()` is unchanged (it already
+    returns the flattened field list) and is the shorter path when fields are all
+    you need.
+  - **`isMetaEnvelope`, exported from `@objectstack/rest`, is REMOVED.** It
+    existed only to tell the two shapes apart. There is one shape now, so the
+    replacement for `isMetaEnvelope(r) ? r.item : r` is `r.item`.
+  - **Not converged, deliberately**: `?layers=true` still answers the layered
+    diagnostic projection `{ type, name, code, overlay, overlayScope, effective,
+validation }`. Collapsing three layers into one `item` would delete the
+    diagnostic. Unaffected unless you pass that flag.
+
+### Minor Changes
+
+- 96d3d4d: The two machine-readable endpoint surfaces announce only the declarations the runtime actually serves
+
+  `GET {basePath}/meta/api` and `GET {basePath}/openapi.json` enumerated declared `api` items
+  through the metadata protocol (ObjectQL SchemaRegistry + `sys_metadata`). Whether a declared
+  route is SERVED is decided by a different reader — `IMetadataService.matchEndpoint` and the
+  endpoint matcher behind it, which sees the metadata manager's registry and its registered
+  loaders. A real boot measured the two disagreeing: an `api` row written through
+  `PUT /meta/api/{name}` was enumerated by both surfaces — the OpenAPI document publishing it as
+  a path with `security: []`, i.e. as needing no credentials — while every request to it answered 404.
+
+  Both surfaces now ask the matcher, per declaration, and announce only what comes back. An
+  `/openapi.json` is what SDKs, codegen and AI clients generate from, so an endpoint advertised
+  there that does not exist propagates into everything built on top of it.
+
+  **What changes for you:** an `api` declaration that this runtime will not serve disappears from
+  both surfaces. That covers a row created by a runtime/Studio metadata write rather than
+  published from a stack artifact, and one excluded at load by the ADR-0121 publish gates (for
+  example `authRequired: false` with no armed `rateLimit`). If a declaration you expected has
+  vanished, it was already answering 404 — the surface has stopped mis-reporting it, and the
+  server log now names each omitted declaration, its route, and why. Publish it through a gated
+  path (a stack artifact, or `publishPackage` with the package's `manifest.namespace`) to make it
+  real. Endpoints declared in a stack artifact are unaffected: they are served, so they are still
+  listed and still documented in full.
+
+  Two surfaces deliberately keep their previous behaviour: `GET /meta/api?preview=draft` answers
+  "what is pending", which is by construction not the served set, and the single-item
+  `GET|PUT|DELETE /meta/api/{name}` routes stay reachable so an unserved declaration can still be
+  inspected and removed.
+
+  Hosts that embed `RestServer` directly get a new optional final constructor argument,
+  `metadataServiceProvider`, resolving the `metadata` service. `rest-api-plugin` wires it; a host
+  that does not pass it keeps the old enumerate-everything behaviour and logs, once, that the
+  surfaces can no longer promise they describe only served routes.
+
+- 75f82f3: **`/openapi.json` 的 built-in 路由段改由 rest 按自身路由事实产出(#5588,维护者裁定 C 第一棒)**
+
+  发布出去的 `GET {apiPath}/openapi.json` 里,built-in 路由那一段**一条都不存在**:真实 boot 逐条探测,7 条 path / 10 个 operation **0/10 命中**。段落由 `packages/spec/scripts/build-openapi.ts` 按字面量 `basePath = '/api'` 手写,于是路径全部缺 `/v1`(CRUD 还缺 `/data`);`PUT {object}/{id}` 写错动词,服务器对 `PUT` 明确回 405;`/api/meta/types` 全仓无此路由;`/api/.well-known/objectstack` 是 runtime dispatcher 的路由、服务在**根路径**上而非 API base 下。照这份文档生成客户端,每一个数据调用都 404。
+
+  这个座位上也不可能写对:`apiPath` 是部署级配置(`api.apiPath ?? api.basePath + '/' + api.version`),随包发布的静态 JSON 无法为所有部署拼对前缀。
+
+  **改法**:built-in 段的属主是**挂载这些路由的包**(ADR-0076 一路由一属主;本文档的属主由 #5078 的真实 boot 坐实为 `packages/rest`)。serve 期流水线现在从 `routeManager.getAll()`——路由器自己用来匹配请求的那张表,请求时读取——产出该段,并**丢弃**静态产物里带来的 `paths` 而不是与之合并(合并等于把错误的段再发布一次;spec 侧的生成要到第二棒 #5744 才摘除)。同一张表既决定「谁被服务」又决定「谁被描述」,幽灵行因此在结构上不可能存在:四条 bulk 路由只在 protocol 实现了 `batchData` / `createManyData` 时注册,于是也只在那时被描述。
+
+  - 路径前缀跟随实际配置的 `apiPath`,project-scoped 镜像有自己的文档(不再把每条路径写两遍);
+  - 动词是注册时的动词(`PATCH` 就是 `PATCH`);
+  - 覆盖面:该 base 下经本服务器 `RouteManager` 挂载的**全部**路由(默认 boot 78 条,对比旧段的 10 个 operation),`rest-route-ledger.ts` 中 `source: 'route-manager'` 的各 family 全含,不按 `disposition` 裁剪——`server-only` / `public` 也是被服务的 HTTP 面。**不含**两个 `direct-mount` registrar(`package-routes.ts` / `external-datasource-routes.ts`,9 行):它们绕过 `RouteManager` 直接注册且受服务开关约束,本服务器**不持有**它们本次 boot 是否挂载的事实,而凭空补上正是本单要修的那类缺陷;也不含其它包挂载的路由(dispatcher 根路由、`service-storage`、`service-i18n`);
+  - 不编造:请求/响应 schema、状态码、query 参数一律不生成(旧段的 `CreateRequest` / `UpdateRequest` `$ref` 除了挂在 404 的路径上,连线上形状都是错的——`{ data }` 信封 vs 裸记录体,spec 自己的路由目录 `plugin-rest-api.zod.ts` 里已记录这一点)。每个 operation 只写从注册读出的 `summary` / `tags`、从路径机械推导的 `operationId` 与 path 参数,响应写 `default`(成功状态是逐 handler 的事实,写 `200` 对 201/204 的路由就是错的);
+  - 逐 operation 的 `security` 只在注册带 `public` 标签时写 `[]`(匿名表单),其余继承文档级要求——对 `/discovery`、`/openapi.json` 这类实际匿名的路由属于**故意少说**:注册没有携带鉴权事实,而「不需要凭据」是写错会漏数据的那个方向。
+
+  `{object}` 展开与声明式端点合并两步原样保留,只是展开的模板终于是真实存在的路由(`/api/v1/data/{object}` 及其同族)。`components.schemas` / `info` / `securitySchemes` 仍来自 `@objectstack/spec` 并原样保留——那是它真正拥有的部分。
+
+- 1203bb2: **声明式端点进 OpenAPI 文档;`/openapi.json` 的影子属主摘除(#5040 E6,并入 #5078)**
+
+  `GET {basePath}/openapi.json` 只有一个属主,而且实测坐实是 `packages/rest`(#5078:真实 boot 拿到 355KB 的 OpenAPI 3.1 文档,`servers[0]` 按 Host 注入、`{object}` 展开出 199 条 paths、两条 `x-template` —— 三个指纹全部是 rest-server 的行为)。因此 `apis:` 端点的文档面加入 **rest-server 既有的 enrichment 管线**(与 `{object}` 展开同根、同一次请求、同样 best-effort),而**不是**在某个 metadata service 上实现 `generateOpenApi` —— 那会造出 ADR-0076 第 1 条明令禁止的第二属主。E1 的契约成员因此已剔除。
+
+  每条声明贡献一个 path 条目:`path` 原样、`method` 小写作为 Operation 键、`operationId` = `name`,以及词表**真正带有**的两个文档字段 `summary` / `description`(缺省即缺省,不生成替身)。除此之外只写「执行器会怎么对待这条声明」的事实,逐条注明出处:`object_operation` 的 `get`/`update`/`delete` 记录 id 取 `query.id`(词表无路径模板语法)、`create` 答 201 其余 200、`script` / `proxy` 与缺 `objectParams` 的 `object_operation` 答 **501**。不编造任何 request/response schema —— 出厂文档的 `components.schemas` 是空的,凭空写 `$ref` 只会得到悬空引用。
+
+  `authRequired` 由 schema parse 物化(缺省即 `true`),为 true 的条目引用**从文档自身读出**的 security 方案(不在 rest 里硬写方案名,否则就是第二处需要保持正确的地方),为 false 的条目写显式 `security: []` —— 这是 review 时一眼能看见的那个形状。不满足 `ApiEndpointSchema` 的存量条目**响亮跳过**并点名(与端点匹配器的装载门同一姿态);同 `method+path` 撞车时按「`name` 字典序在前者胜」裁决,与匹配器**同一条规则**,否则文档会指认一个运行时并不执行的端点;撞上内建路径时内建保留,声明被略过并报错。
+
+  同时摘除 `http-dispatcher.ts` 里的 `generateOpenApi` 探测死分支:该方法在本仓与两个兄弟仓**零实现**,且 boot 实测**没有任何路由**把 `/openapi.json` 送进 `dispatch()` —— 双重死。`route-ledger.ts` 里对应的行与 `LEGACY_CHAIN_PREFIXES` 条目一并移除(原注记「falls through when metadata service lacks a generator」把「从来没有」写成了「有时没有」,正是 #5078 立单的失准点;把 prefix 留在一张自述为「if-chain 分支」的清单里,会在同一个 PR 里再造一次同样的谎)。该路由的唯一台账行在 `packages/rest/src/rest-route-ledger.ts`,一直是准的。
+
+  **现网行为零变更**:publish / validate 对非空 `apis:` 仍然硬拒(E7 前不撤),所以今天枚举出的是空集,enrichment 原样返回同一个文档对象 —— 服务出去的字节与本次改动前逐字节相同,并有测试钉住。
+
+### Patch Changes
+
+- 978fed2: fix(analytics,rest): five dataset refusals declare `DATASET_INVALID` / 400 themselves, and the route's message-sniffing list shrinks to one entry (#5367)
+
+  `POST /analytics/dataset/query` answered `400 DATASET_INVALID` for six error
+  families because the route recognised their **prose**, not because the errors
+  said anything about themselves. #5352 gave the catch an ADR-0112 envelope branch
+  (`error.code` + a 4xx `error.status`, read first) and had to leave a hardcoded
+  list of message substrings behind it, since all six producers were still bare
+  `throw new Error(…)`:
+
+  ```
+  /not declared in the dataset|not backed by a declared relationship|
+   not supported by the v1 dataset runtime|read-scope-sql|
+   not a selected dimension or measure|is not a subset of the selected dimensions/
+  ```
+
+  That made the HTTP status of six families a property of their wording.
+  Rephrasing `dataset-compiler`'s "is not declared in the dataset's `include`" —
+  no logic change — moved that refusal from 400 to 500, i.e. re-opened #5352 for a
+  different family, and no test and no gate would have gone red. Prime Directive
+  #12 permits an accommodation like that only while it is declared, loud, tested
+  **and removable on a schedule**; #5366 delivered the first three and nothing
+  carried the fourth.
+
+  **Five producers now declare their own verdict.** A new
+  `dataset-refusal.ts` in `@objectstack/service-analytics` exports
+  `datasetInvalidError` — the same shape as that package's existing
+  `invalidFilterError` (`INVALID_FILTER` / 400) and `assertDimensionFields`
+  (`INVALID_FIELD` / 400) — and five sites throw through it:
+
+  - `dataset-compiler.ts` — a measure whose aggregate the v1 runtime cannot lower;
+    a dimension/measure traversing a relationship path the dataset never declared
+    in `include`;
+  - `dataset-executor.ts` — an `order` key that is not a selected dimension or
+    measure; a `totals` grouping that is not a subset of the selected dimensions;
+  - `native-sql-strategy.ts` — a join outside the dataset's declared allowlist.
+
+  Their five entries are gone from the route's list, which is now a single
+  `read-scope-sql` test.
+
+  **`read-scope-sql` deliberately stays.** Its ten fail-closed refusals are RLS
+  read-scope lowering failures whose inputs are an admin-authored policy and a
+  compiler-generated join alias — not caller input — so `DATASET_INVALID` ("your
+  request is invalid") may well be the wrong verdict and choosing the right one is
+  a separate judgement, still tracked by #5367. Deleting the entry before that
+  judgement lands would regress those ten from `400 DATASET_INVALID` to 500.
+
+  **No outward behaviour change for the five.** They answered
+  `400 DATASET_INVALID` before and answer `400 DATASET_INVALID` now, with the same
+  message; what changed is the mechanism, from message-matching to the producer's
+  own declaration. The one visible difference is for a bare `Error` that merely
+  _resembles_ one of those messages: it is no longer promoted to a 400. That is the
+  point — a phrase is no longer a classification.
+
+  `DATASET_INVALID` is registered in `ERROR_CODE_LEDGER` under
+  `@objectstack/service-analytics` as well as `@objectstack/rest` (provenance, per
+  ADR-0112 D3; the code itself is unchanged and the union does not grow), and the
+  constructor types it as `RegisteredErrorCode` so an unregistered code is a
+  compile error rather than a body some route rejects at runtime.
+
+  Coverage: `dataset-refusal-envelope.test.ts` (service-analytics) pins each of the
+  five refusals against its real producer — the refusal SET first, green before and
+  after, then the envelope; `analytics-dataset-refusal-envelope.test.ts` (rest)
+  drives all five end-to-end through a real `AnalyticsService` with positive
+  controls on both the aggregate and raw-SQL paths; and
+  `analytics-filter-refusal-envelope.test.ts` pins the deletion in both directions
+  — the five messages answer 400 when enveloped and 500 when bare, so re-adding a
+  regex entry turns it red.
+
+- c36abfe: fix(service-analytics,rest): an analytics dimension over a missing field answers 400 INVALID_FIELD, not a driver 500 (#5520)
+
+  #4437 gave a **measure** over a non-existent field a `400 INVALID_FIELD` naming
+  the field, because a driver error class must never be the caller's `error.code`
+  for a caller-shaped mistake (ADR-0112). It covered the measure half only, so the
+  identical typo one request key over still reached the driver as a `GROUP BY`
+  column:
+
+  ```
+  POST /analytics/query {"cube":"account_metrics","measures":["account_count"],"dimensions":["bogus_dim"]}
+  → 500 {"code":"SQLITE_ERROR","message":"Internal server error"}
+
+  # the control group on the same route, already fixed by #4437
+  POST /analytics/query {"cube":"account_metrics","measures":["bogus_measure"]}
+  → 400 {"code":"INVALID_FIELD","message":"Measure 'bogus_measure' … Valid measures: …"}
+  ```
+
+  **The gate.** `ensureCube` now runs `assertDimensionFields` alongside
+  `assertMeasureFields` on every path, so a dimension whose source column the
+  backing object does not have is refused **before** any SQL is built, with the
+  same envelope the measure gate uses: `INVALID_FIELD` / 400 plus
+  `field` / `object` / `param`, a message naming the field, the valid dimensions,
+  and the object's known field list. `query`, `generateSql` and `queryDataset` are
+  all covered, and a rejected query leaves nothing behind in the cube registry.
+  `timeDimensions` are covered too — they resolve through the same
+  `cube.dimensions` bag and produced the same 500 — with `param` reporting which
+  request key carried the bad name.
+
+  **What deliberately did not change:** grouping by a REAL field the cube never
+  declared as a dimension (`dimensions: ["phone"]`) still works. The gate asks
+  "does the _object_ have this field", never "did the cube declare this
+  dimension". A cube whose `sql` is an expression, a dotted relation dimension,
+  and a host that wires no field-name probe are all stood down on, exactly as the
+  measure gate stands down.
+
+  **The SQL echo, same request.** `POST /analytics/dataset/query` composed its own
+  5xx body and echoed the error message verbatim. Knex prefixes the offending
+  statement to its message, so the caller received the generated SQL — physical
+  table and column names included:
+
+  ```
+  500 {"code":"ANALYTICS_QUERY_FAILED",
+       "error":"SELECT bogus_dim AS \"bogus_dim\", COUNT(*) AS \"account_count\"
+                 FROM \"crm_account\" GROUP BY bogus_dim - no such column: bogus_dim"}
+  ```
+
+  The sibling face never leaked it: `/analytics/query` exits through the
+  dispatcher, which has applied the shared `looksLikeInternalErrorLeak` predicate
+  to every >= 500 message since #3867. That same predicate now guards this route's
+  500 body. Classification is untouched — the status stays 500, the code stays
+  `ANALYTICS_QUERY_FAILED`, the ADR-0112 envelope branch and the transitional
+  message list are unchanged — and the full text still reaches server logs. A 500
+  whose message does not look like driver output keeps its prose.
+
+- 2f6516e: fix(analytics,rest): an analytics filter refusal reaches the caller as `400 INVALID_FILTER`, not `500 ANALYTICS_QUERY_FAILED` (#5352)
+
+  Misspell an operator in a dashboard widget's filter and analytics refuses it —
+  correctly, and loudly, which is the posture #3948 / #5240 / #5325 / #5334 each
+  argued for one refusal at a time: dropping a predicate the compiler cannot
+  express does not narrow the query, it **widens** it to rows the author excluded,
+  and a chart drawn over the whole dataset looks like a working chart.
+
+  The refusal never reached the author. It landed as `500 ANALYTICS_QUERY_FAILED`
+  — read as "the platform is broken" rather than "your filter has a typo", and
+  counted by ops alerting as a 5xx. The identical mistake on `find()` has answered
+  `400 INVALID_FILTER` since #3948, so one authoring error had two wire shapes,
+  chosen by which face happened to catch it.
+
+  **One defect, two halves — either alone leaves it unfixed.**
+
+  - **Producer** (`filter-normalizer.ts`): seven of its nine refusals were bare
+    `throw new Error(…)` carrying no `code`/`status`. All nine now go through the
+    `invalidFilterError` helper #5334 introduced (`INVALID_FILTER` / 400), which
+    becomes the module's only way to refuse.
+  - **Consumer** (`rest-server.ts`, `POST /analytics/dataset/query`): the catch
+    discarded `error.code` / `error.status` and re-derived the classification from
+    a hardcoded list of message substrings — so a producer that took ADR-0112
+    seriously was punished for it. It now reads the envelope **first**; the
+    substring list is demoted to a fallback for the families that still carry no
+    envelope.
+
+  **Observable behaviour change — read this if you alert or retry on status.**
+  The same request that returned `500 ANALYTICS_QUERY_FAILED` now returns
+  `400 INVALID_FILTER` (and, for two neighbouring conditions whose producers
+  already declared an envelope this route was discarding, `400 INVALID_FIELD` for
+  a measure over a field the object does not have, `404 CUBE_NOT_FOUND` for an
+  unregistered cube). Monitoring that counted these as server faults will see the
+  5xx rate drop and a 4xx rate appear; a client that retries on 5xx will stop
+  retrying a request that could only ever fail the same way. Both are the intended
+  correction — the condition was always the caller's mistake — but they are
+  visible, so they are stated rather than buried.
+
+  **Which inputs are refused did not change.** This changes the SHAPE of the
+  error and nothing about the judgement that produced it: no refusal condition
+  was touched, no input that used to compile now refuses, and no input that used
+  to refuse now compiles. That claim is pinned input-by-input (refusals _and_
+  accepted inputs with their compiled trees) in
+  `filter-refusal-envelope.test.ts`, which is green both before and after the
+  change — only the envelope assertions move.
+
+  The message-substring list survives on purpose. All six of its entries were
+  re-verified as bare `Error`s (`dataset-compiler.ts`, `native-sql-strategy.ts`,
+  `dataset-executor.ts`, `read-scope-sql.ts`), so deleting it would regress those
+  families from `400 DATASET_INVALID` to 500. It is a placeholder for their
+  enveloping, not a second classification mechanism, and it is now documented as
+  such: a new refusal should carry a `code`/`status` and be served by the
+  envelope branch for free. The passthrough is deliberately **4xx-only** and
+  requires **both** `code` and `status`, so an internal fault can never be
+  re-labelled as the caller's fault, and this route never invents a code a
+  producer failed to supply.
+
+- 64cd010: fix(runtime,types)!: `/analytics/query` no longer echoes RLS policy field names — the declared-server-fault withhold is shared by both HTTP boundaries (#5811)
+
+  **Observable behaviour change — read this if you read, log, or assert on
+  `error.message` from a dispatcher-plugin route.** An error that **declares a
+  server fault** in the ADR-0112 envelope (`status >= 500` _and_ a non-empty
+  `code`) now leaves `dispatcher-plugin.errorResponseBase` with its message
+  replaced by `"Internal server error"`. It previously reached the caller verbatim
+  unless it happened to _sound_ like a SQL/driver dump. This applies to every route
+  that plugin mounts — `/analytics`, `/packages`, `/i18n`, `/automation`, `/auth`,
+  `/notifications`, `/mcp`, … — not only the one that motivated it. Nothing a
+  machine reads changed: the producer's `code` still arrives in the response
+  (`error.code`, promoted there from `details` by the shared envelope builder,
+  #3842), the status is untouched, and the full original text still goes to the
+  server log and `errorReporter` via `__obsRecordedError`.
+
+  ## What was wrong
+
+  #5367 (maintainer ruling 2026-08-06) made `read-scope-sql.ts`'s ten fail-closed
+  RLS lowering refusals `READ_SCOPE_COMPILE_FAILED` / 500 and taught
+  `POST /analytics/dataset/query` to withhold their message, because those messages
+  name the field names and comparands of an **administrator's** sharing rule:
+
+  ```
+  [read-scope-sql] unsafe field identifier "secret_policy_field" — refusing to
+  build read scope (fail-closed).
+  ```
+
+  The caller never wrote that field name and must not be able to read it out of an
+  error body. But the **sibling** analytics face was never closed.
+  `compileScopedFilterToSql` runs on both `NativeSQLStrategy.applyReadScope` and
+  `ObjectQLStrategy`'s echoed SQL, both of which serve `POST /analytics/query`,
+  which exits through `dispatcher-plugin.errorResponseBase`. That exit's only
+  message guard was `looksLikeInternalErrorLeak` — a heuristic over SQL/driver
+  _phrasing_ — and all eleven read-scope message shapes return `false` from it.
+  Measured at that boundary: **11 of 11 echoed verbatim**, at 500, with the policy
+  content in `error.message`. A real reachable disclosure, not a theoretical one.
+
+  ## What changed
+
+  - **`@objectstack/types` gains `declaresServerFault(err)`**, exported from
+    `error-leak.ts` beside `looksLikeInternalErrorLeak`. The heuristic asks whether
+    a message _sounds_ internal; the declaration asks whether the producer _said
+    so_. `error-leak.ts`'s own file header already states the principle — "do not
+    ship driver internals to clients" is a property of the HTTP boundary, not of
+    one router — and this is the second predicate that principle asks for.
+  - **Both boundaries read it.** `dispatcher-plugin.errorResponseBase` gains the
+    withhold (the fix); `rest-server.ts`'s `/analytics/dataset/query` catch drops
+    its in-line copy of the same test in favour of the shared one. #5808 wrote that
+    rule in-line on purpose — promoting a rule with one consumer is a speculative
+    surface — and this is the second consumer, so it was promoted rather than
+    duplicated (`#3843`/`#3867` paid for the two-implementations shape twice).
+    The REST face's verdict is unchanged in every case: same `status >= 500` plus
+    non-empty `code` test, over the same two fields.
+
+  ## What deliberately did NOT change
+
+  - ⛔ **This is not "withhold every 5xx".** #5667 kept **undeclared** 5xx errors
+    legible on purpose: a bare `Error` from our own code ("no strategy can handle
+    query …") is the operator's own bug report, names nothing tenant-sensitive, and
+    still falls to `looksLikeInternalErrorLeak` alone. A 5xx carrying only half an
+    envelope (a status with no code) is likewise still readable — inventing the
+    withhold for it would be the consumer-side leniency Prime Directive #12 removes.
+  - **4xx is untouched.** `declaresServerFault` requires `status >= 500`, so a
+    deliberate business/validation answer can never be swallowed by it.
+  - **`statusCode` is not accepted as a substitute for `status`.** `status` is the
+    channel ADR-0112 declares; making a disclosure rule depend on which spelling a
+    producer reached for would be the same leniency in a different place.
+  - **The heuristic was not taught to recognise `[read-scope-sql]`.** That would be
+    more prose sniffing — the mechanism #5352/#5367 exist to remove — and would only
+    ever cover the family someone remembered to add.
+
+  Coverage: `analytics-query-read-scope-withhold.test.ts` (runtime) drives six RLS
+  policy shapes end-to-end through a **real** `AnalyticsService` on the real
+  native-SQL path and the real mounted route, asserting the 500, that the whole
+  serialized body contains no policy detail, that `error.code` still carries
+  `READ_SCOPE_COMPILE_FAILED`, and that the full text is still on the
+  `__obsRecordedError` side-channel — plus a positive control and both sides of the
+  declared-vs-undeclared tiering. `error-leak.test.ts` (types) pins the predicate
+  directly, including that all eleven read-scope shapes stay invisible to the
+  heuristic. The REST face's existing `analytics-read-scope-refusal-envelope.test.ts`
+  is green before and after, unchanged, which is the pin on the refactor.
+
+- fb3d99b: fix(analytics,rest)!: an RLS read-scope lowering failure is a `500`, not the caller's `400` — and its policy detail no longer reaches the response (#5367)
+
+  **Observable behaviour change — read this if you alert, retry, or assert on status.**
+  A request whose dataset carries an RLS read scope that `read-scope-sql.ts` cannot
+  lower used to answer `400 DATASET_INVALID` with the refusal message echoed
+  verbatim. It now answers `500 ANALYTICS_QUERY_FAILED` with the message withheld
+  (`"Internal server error"`); the full text goes to the server log. Monitoring that
+  counted these as client errors will see a 4xx disappear and a 5xx appear, and a
+  client retrying on 5xx will now retry a request that cannot succeed until an
+  administrator fixes the policy. Both follow from the correction below and are
+  stated rather than buried.
+
+  ## What was wrong
+
+  These ten fail-closed refusals were the last family `/analytics/dataset/query`
+  classified by **prose** — the final entry of the hardcoded message-substring list
+  #5352 introduced, which #5367's first PR had already shrunk from six entries to
+  one. Two defects in one verdict:
+
+  - **Misattribution.** `compileScopedFilterToSql(filter, alias)` receives an RLS
+    `FilterCondition` the security service compiled from an **administrator's**
+    sharing rule / permission set, and a join alias the **dataset compiler**
+    generated. Neither is caller input — the caller's own predicate goes through
+    `filter-normalizer.ts` and has answered `INVALID_FILTER` / 400 since #5352. So
+    what can arrive here is a broken policy, or drift between two of our own
+    components (#5557's `$regex` was literally the second case). For this request's
+    caller both are a **server** fault; `400` told them to fix a request that was
+    never wrong and kept the real fault out of 5xx alerting.
+  - **Disclosure.** A 400 echoed the message, so
+    `unsafe field identifier "secret_policy_field"` and
+    `unsupported operator "$regex" on "owner_email"` handed a tenant the field names
+    and comparands of the RLS policy governing them.
+
+  The maintainer ruled on 2026-08-06 (option B on #5367's decision card; option A
+  was `READ_SCOPE_INVALID` / 422, rejected because no consumer reads a code on this
+  path, a 4xx misreports a condition the client cannot fix, and 422 would have left
+  the disclosure question to be re-decided message by message).
+
+  ## What changed
+
+  - `read-scope-sql.ts` gains a module-local `readScopeCompileError` — the twin of
+    `filter-normalizer.ts`'s `invalidFilterError`, and likewise **the only way the
+    module refuses**. All ten sites carry `READ_SCOPE_COMPILE_FAILED` / **500**.
+    `:104`'s alias-vs-field split (option C on the card) collapses under B: both
+    branches answer the same verdict, pinned so the collapse is a recorded decision.
+  - `rest-server.ts` loses branch ② entirely. **The message-sniffing mechanism is
+    fully retired** — nothing in this catch reads prose any more, and #5367's
+    Prime-Directive-#12 retirement schedule ("declared, loud, tested AND removable
+    on a schedule") is paid off.
+  - The route's 5xx branch now withholds the message of any producer that
+    **declares** a server fault (`status >= 500` with a `code`). This was needed
+    rather than inherited: `looksLikeInternalErrorLeak` (#3867/#5520) is a heuristic
+    over SQL/driver _phrasing_, and measured, every read-scope message returns
+    `false` from it — so retiring the list alone would have moved the policy content
+    from a 400 body into a 500 body instead of out of the response. Teaching that
+    heuristic to recognise `[read-scope-sql]` would have been _more_ message
+    sniffing, so the rule keys on the ADR-0112 envelope instead. **Undeclared** 5xx
+    errors keep #5667's tiering, so a self-authored fault ("no strategy can handle
+    query …") stays readable.
+  - `READ_SCOPE_COMPILE_FAILED` is registered in `ERROR_CODE_LEDGER` under
+    `@objectstack/service-analytics` (ADR-0112 D3) and typed as
+    `RegisteredErrorCode` at the constructor, so an unregistered code is a compile
+    error. It is legible on the wire through the sibling `/analytics/query` exit,
+    which puts a thrown `err.code` in `error.details.code` (#3842).
+
+  **Which inputs are refused did not change.** No refusal condition moved: nothing
+  that used to lower now throws, and nothing that used to throw now lowers. That is
+  pinned input-by-input — refusals _and_ accepted read scopes with their compiled
+  SQL and bind params — in `read-scope-refusal-envelope.test.ts`, which is green both
+  before and after; only the envelope assertions move.
+
+  Coverage: `read-scope-refusal-envelope.test.ts` (service-analytics) drives all ten
+  sites through the real compiler; `analytics-read-scope-refusal-envelope.test.ts`
+  (rest) drives five policy shapes end-to-end through a real `AnalyticsService`,
+  asserting the 500, that the body contains no policy detail, and that the withheld
+  text is present in the log — plus a positive control and both sides of the
+  declared-vs-undeclared withhold.
+
+- c001422: feat(spec): declare `routes.mcp` on `ApiRoutesSchema`, and extend the discovery conformance gate one level down (#5679)
+
+  `/discovery` advertises `routes.mcp`, `objectui` reads it, and
+  `ApiRoutesSchema` never declared it. This is #4828's defect one level down —
+  with the opposite disposition: `endpoints` was retired because a census found
+  no reader, while `mcp` has two real ones (`ConnectAgentWidget.tsx` and
+  `AgentConnectSection.tsx` both gate the Integrations connect card on it), and
+  it is in fact the only `routes.*` key anything in `objectui` reads. So it is
+  declared, not removed.
+
+  Why it was a defect and not tidiness: `ApiRoutesSchema` is a plain `z.object`,
+  which **strips** unknown keys. Any consumer parsing `/discovery` through the
+  spec dropped `routes.mcp` silently — the connect card would blank with no
+  error. Nothing broke yet only because those two readers happen to read raw
+  JSON.
+
+  - **`ApiRoutesSchema` declares `mcp: z.string().optional()`**, as measured off
+    both producers rather than guessed: a path string (`/api/v1/mcp`), always the
+    **unscoped** base — `/mcp` is mounted bare, so a scoped mount advertising
+    `/api/v1/environments/env_alpha/data` still advertises `/api/v1/mcp` — and
+    `optional`, not `nullable`: the key is absent (rest-server `delete`s it, the
+    dispatcher leaves it `undefined`) when MCP is disabled or unserveable.
+    Neither producer ever emits `null`.
+  - **`@objectstack/rest` drops the two `as any` casts** at the emit site. That is
+    type-only — the emitted body is byte-identical — but the cast's disappearance
+    is the structural proof: with the key undeclared, removing it produced two
+    `TS2339 Property 'mcp' does not exist`; with it declared, `tsc --noEmit`
+    returns to its ratcheted baseline.
+  - **The #4828 conformance gates now cover `routes` keys**, not just top-level
+    ones, in all three producer packages, deriving the allowance from
+    `ApiRoutesSchema` the same way the top-level check derives it from the
+    protocol schema. Extended one level, not recursed — full recursion stays out
+    of scope, and `capabilities` / `services` are `z.record`s whose keys are open
+    by design.
+
+  - **`@objectstack/client`'s conventional route table gains an `mcp` row.** That
+    table is `Record<keyof ApiRoutes, string>` — total by design — so a newly
+    declared route owes a convention, and the public `ApiRouteType` (`keyof
+ApiRoutes`) widens by one member. The path is `/api/v1/mcp`, which is what
+    both producers emit, so the fallback agrees with the discovered value instead
+    of competing with it. Resolution behaviour is unchanged: `getRoute()` still
+    prefers the discovered route, and the pre-existing catch-all already produced
+    the same string.
+
+  Corrects one detail of the issue's premise: the runtime dispatcher's
+  `getDiscoveryInfo()` **does** also emit `routes.mcp` (its routes literal always
+  carries the key, holding the path or `undefined`), so both producers were
+  affected, not just REST — and the new gate went red on both before the fix.
+
+- aeb9b27: **发布出去的 OpenAPI 文档 `components.schemas` 不再是空的,6 个 `$ref` 不再悬空(#5168)**
+
+  `GET /api/v1/openapi.json` 的 base spec 由 `packages/spec/scripts/build-openapi.ts` 生成,它把九个契约 schema(`CreateRequest` / `ApiError` / `ListRecordResponse` / …)转成 JSON Schema 填进 `components.schemas`。收集判据写的是 `typeof schema === 'object' && '_zod' in schema`,而这九个 schema 全部经 `lazySchema()` 包装 —— 其 Proxy target 是 `function lazyZod() {}`,于是 `typeof` 是 `'function'` 而不是 `'object'`,判据第一段就短路,九个一个都没进去。`paths` 里那 6 个 `$ref` 是手写字面量,不受影响照常写出,结果是**一份 `components.schemas` 为 `{}`、6 个 `$ref` 全部悬空的文档被发布出去**,覆盖 `/api/{object}` 与 `/api/{object}/{id}` 上全部 CRUD 操作的请求体与响应体。
+
+  判据放宽为同时接受 `'object'` 与 `'function'`。`'_zod' in schema` 那一段对 Proxy 本来就是有效的 —— `lazySchema` 专门维护了 `_zod` facade 供 `toJSONSchema` 遍历 —— 所以 `lazySchema` 本身不需要改动。对照实验坐实了唯一变量就是 Proxy:同一份源码下 `npx tsx scripts/build-openapi.ts` 得到 `Components: 0`,而 `OS_EAGER_SCHEMAS=1`(`lazySchema` 自带的绕过 Proxy 应急开关)得到 `Components: 9`。修复后不带任何环境变量即为 `Components: 9`。
+
+  两类消费者直接受益:`GET /api/v1/docs` 的 Scalar viewer 现在有 schema 可渲染;从该文档做客户端代码生成的集成方(openapi-generator / orval / …)不再在解析期撞上 unresolvable reference。
+
+  **同时补上防复发的门禁。** 这个缺陷三个层次同时可见(空 components、悬空 ref、控制台明晃晃的 `Components: 0`)却没有任何一处红 —— `gen:openapi` 是全仓两个完全无门禁的生成器之一。生成器现在在**写盘之前**自检两条,任一不满足即以非零码退出,自恰不了的文档根本不会被写出来:
+
+  1. **每个本地 `$ref` 都必须解析得到。** 按 JSON Pointer 解析而不是按 `#/components/schemas/` 前缀匹配,将来新增的 `#/$defs/…` 引用自动被覆盖;报错逐条点名悬空的 `$ref` 及其在文档中的位置,并把「已定义的 schema 列表」一并打出来 —— 哪一侧是空的是读者最先需要的信息。
+  2. **没有 schema 被静默降级。** 九个契约 schema 是一张字面清单,某个名字没产出东西永远是缺陷而不是「这个可选」。原先的循环写成 `if (像 zod) { 收 }` 且没有 `else`,正是这个「静默跳过」的形状让九次跳过发布成了空文档;现在**声明即强制**,漏掉的名字会被点名。`z.toJSONSchema()` 抛错时原先会塞一个 `{type:'object'}` 占位描述冒充契约,这条同样改为响亮失败 —— 当前九个全部干净转换,零占位。
+
+  门禁接在生成器内部而不是单独的 `check:` 脚本,因为 `packages/spec/json-schema/` 是 gitignore 的、每次 `pnpm build` 重新生成,独立检查脚本无论如何都要先跑一次生成器才有东西可查。「产物自恰」这类断言比「产物最新」更便宜,且不需要任何基线快照。
+
+  `packages/rest` 侧无行为改动:声明式端点的 enrichment 仍然只写 `type: object` 而不编造 `$ref` —— 九个契约 schema 是通用 CRUD 信封,不是某个具体对象的 body 形状 —— 但三处以现在时陈述「`components.schemas` 是空的」的注释已按事实更新。
+
+- 39396bd: REST 的显式状态直通:4xx 错误消息超过 500 字符时**截断**,不再整条替换成 `Request failed`
+
+  `mapDataError` 与 `resolveErrorResponse`(`sendError` 的取值端)两处 4xx 直通分支,过去都以 500 字符为界把整条 message 换成字面量 `Request failed` —— `status` 和 `code` 照常落地,正文一个字不剩。这把激励方向弄反了:驱动层那些拒收信息**唯一的存在意义**就是告诉作者哪个操作符/字段写错了、协议是怎么声明的,而 driver-sql 里写得最细的两条(#5158 未降解的 `FilterArray`、#5347 非布尔 `$null` 比较值)恰好都越过 500 字符,于是客户端只收到 `{ "code": "INVALID_FILTER", "error": "Request failed" }`。更反直觉的是:这两条**不带** `status` 时反而能原文直达(走 `mapDataError` 末尾的 `{ status: 400, body: { error: raw } }`),#4436 给它们加 `status: 400` 是为了赋予 ADR-0112 的 wire 身份,却在这一档让可读性变差了。
+
+  现在超长消息按 `message.slice(0, 499) + '…'` 截断,与驱动侧 `safeShapePreview` 同源。这些消息把主句(操作符、字段、path、收到了什么、协议怎么声明)放在最前,被截掉的是尾部的归因和 issue 号 —— 本就该留在日志里而非响应里的部分。上限仍是 500,变的是**到达上限时的处理方式**;短于 500 的消息逐字不变。
+
+  影响面不止过滤器:任何携带 4xx `status` 的领域错误同享此修复,包括 metadata save 校验的 422(实测一条五 issue 的 `INVALID_METADATA` 就在这条线上下)、plugin-sharing 的 record-scope 403 等。
+
+  `sendError` 一侧的直通区间是 400–599,其中 **5xx 的整条替换刻意保持不变**:4xx 的正文是写给调用方的补救说明,5xx 的正文是服务端故障的日志诊断 —— 这与 `mapDataError` 同族分支「deliberately limited to 4xx」的既有取向一致。
+
+- 577cd27: fix(rest): a declared 5xx no longer ships its own message to the client (#5437)
+
+  **Behaviour change — read this if you operate a deployment or parse REST error
+  bodies.** An error that carries an explicit `status` of 500 or above now reaches
+  the client as `{ "error": "Internal server error", "code": "<the producer's
+code>" }`. The status and the code are unchanged; only the free-text message is
+  withheld, and the full original text is written to the server log.
+
+  **What was wrong.** `sendError` — the error path of the metadata, UI, discovery
+  and batch routes — passed an explicit status straight through for the whole
+  400-599 band, so a declared 5xx returned `error.message` verbatim without
+  passing through any of the sanitizing heuristics (`isSqlLeak`,
+  `looksLikeInternalErrorLeak`, the `Internal data error` envelope). The sibling
+  branch in `mapDataError` stops at 4xx on purpose, with the reason written down:
+  "5xx messages keep going through the sanitizing heuristics below so
+  internal/SQL details never reach the client verbatim". Two opposite verdicts on
+  one question, and the routes that report through `sendError` got the permissive
+  one.
+
+  That was reachable, not theoretical. `metadata-protocol` interpolates the raw
+  driver error into two client-facing 500s — the customization-overlay persist and
+  delete failures — so a real driver line such as `SQLITE_ERROR: no such table:
+sys_metadata`, `relation "sys_metadata" does not exist`, or a unique-constraint
+  payload naming physical columns was returned to whoever made the request. The
+  only thing standing in the way was a 500-character bound, and driver errors are
+  far shorter than that. Length was never a proxy for leakage; on this side of the
+  bound it failed open.
+
+  **Accepted cost.** A 5xx message written _for_ the caller now reaches them as
+  the generic sentence plus its code. Two concrete examples: the overlay-persist
+  failure's "In-memory registry was updated but will be lost on restart", and the
+  atomic-batch refusal's "retry without options.atomic, or probe
+  capabilities.transactionalBatch on /discovery first". Both remain fully readable
+  in the server log, and the machine-readable `code` (`OVERLAY_PERSISTENCE_FAILED`,
+  `NOT_IMPLEMENTED`) still rides on the response, so a client keying on codes is
+  unaffected. If you were surfacing 5xx `error` text in an operator console, read
+  it from the log instead — `[REST] Unhandled error` for a genuine fault, and a
+  new `[REST] 5xx message withheld from client` line for the 502/503 lifecycle
+  statuses that the unhandled-error predicate deliberately keeps quiet.
+
+  The message is dropped unconditionally rather than filtered by keyword: a
+  predicate would only move the question to "does the heuristic know this
+  dialect", which is the failure mode that produced the bug. 4xx behaviour is
+  untouched — an over-long client message is still truncated rather than erased
+  (#5423 / #5436).
+
+- 5897552: fix(rest): expected 4xx no longer logged as "[REST] Unhandled error" with a stack (#4886)
+
+  Opening Studio flooded the server log with stack traces. The designer probes
+  `GET /meta/:type/:name?state=draft` on every panel to decide whether to show
+  "unsaved draft" state, and "no draft exists" is the overwhelmingly common
+  answer — true of every artifact nobody is currently editing. `getMetaItem`
+  throws a structured `{ code: 'NO_DRAFT', status: 404 }`, the client got a clean
+  404 and handled it fine, but the route logged it anyway:
+
+  ```
+  [REST] Unhandled error: Error: [no_draft] No pending draft exists for app/showcase_app.
+      at _ObjectStackProtocolImplementation.getMetaItem (…)  { code: 'NO_DRAFT', status: 404 }
+  ```
+
+  **45 of these in one browsing session** — by far the dominant entry in the log,
+  which is how a genuine 500 goes unnoticed, and it misreports severity: nothing
+  was broken.
+
+  The metadata routes had 29 catch blocks logging unconditionally. The data
+  routes already consulted `isExpectedDataStatus` / `isExpectedQueryRejection` —
+  but in four different open-coded spellings across 12 sites, and
+  `isExpectedQueryRejection`'s docblock records an earlier lap of exactly this
+  drift (the filter and sort codes shipped without joining the list, so every
+  rejection they produced was logged as unhandled too).
+
+  Both families now decide through one predicate behind one door,
+  `handleRouteError(res, error, object?)`: it resolves the response once — the
+  same structured-status passthrough or `mapDataError` envelope `sendError`
+  already produced — logs only when that resolved response is a genuine fault,
+  then sends it. `isExpectedDataStatus` and `isExpectedQueryRejection` have no
+  other callers left, so the two families cannot drift apart again.
+
+  Expected now means an explicitly recognised client or lifecycle outcome:
+  403/404/409/502/503, the client-caused 400 query-rejection vocabulary, and
+  `VALIDATION_FAILED`. It deliberately does **not** mean "any 4xx" —
+  `mapDataError` degrades an error it recognised nothing about to an un-coded
+  400, and that bucket is where a real handler bug lands, so it stays loud.
+
+  **No wire responses change** — every status and body is byte-for-byte what it
+  was; this only decides whether the log line is printed. Two operator-visible
+  log deltas beyond the metadata fix:
+
+  - the cross-object transactional batch route judged on `status >= 500` alone,
+    which also swallowed that un-coded 400 — a handler `TypeError` inside a batch
+    transaction used to vanish, and now prints;
+  - `updateMany` / `deleteMany` / clone / global search / the public-form routes
+    stop logging normal 404s, 403s and query rejections.
+
+- 91ec1ea: fix(rest): an unclassified route error answers a sanitised 500, not a 400 (#5489)
+
+  **升级须知 — 状态码行为变化。** `@objectstack/rest` 的错误映射 `mapDataError`
+  在所有分类分支都不匹配时,原先的终局兜底是
+  `{ status: 400, body: { error: <原始 message> } }`。这一支现在改为一个消毒过的
+  服务端故障信封:
+
+  ```
+  500 {"error":"Internal server error","code":"INTERNAL_ERROR"}
+  ```
+
+  **为什么。** 400 的语义是「你请求错了」——SDK、fetch 封装、代理和重试策略都据此
+  判定「不要重试,调用方得改点什么」。而真正落到这一支的错误恰恰相反:元数据存储
+  读不到时 `matchEndpoint` 按契约抛错(它抛就是为了让 outage 不伪装成「没有声明
+  任何 endpoint」,ADR-0110 D3),或者干脆是处理器自身的 `TypeError`。两者调用方都
+  修不了,且都**应该**重试。实测:`GET /api/v1/meta/api` 对着一个抛
+  `Error('metadata store unreachable')` 的存储,返回 HTTP 400。
+
+  同时,原始 message 是逐字下发的——而这偏偏是全文件里最没有证据表明可以下发的一
+  条路径:走到这里的前提就是 `looksLikeInternalErrorLeak` 什么都没匹配上,而
+  #5462 已经记过「关键词启发式沉默不等于安全」。实测到的一例:一个声明了
+  `status: 502`、message 为 `connect ECONNREFUSED 10.0.0.5:5432 (internal pool)`
+  的错误,经由数据路由直接调用 `mapDataError` 时,以 400 携带主机与端口下发。
+  沿用 #5464 的纪律:原文进服务端日志,不进客户端(500 不在
+  `isExpectedDataStatus` 内,`handleRouteError` 会打印完整错误对象)。
+
+  **真正的客户端错误一个都没有改变。** 改动前先做了测绘:给这一支加桩,跑完
+  `@objectstack/rest` 全套(48 文件 / 719 用例),落到这一支的只有 6 个错误——本单
+  的存储 outage、两个 502 的 ECONNREFUSED、三个 `TypeError`,没有一个是客户端
+  错误。历史上唯一骑在这条兜底上的客户端错误家族(driver-sql 无法编译的 filter
+  拒绝)已由 #4436 在**生产者侧**声明 `status: 400` + `INVALID_FILTER` 迁走。
+  validation / permission / unknown object / unknown field / not-null 漂移 /
+  unique 冲突 / 沙箱业务拒绝等全部仍由各自分支给出原本的 4xx。
+
+  **`INTERNAL_ERROR` 而非 `DATABASE_ERROR`。** #5462 的 `DATA_STORE_FAULT`
+  (`500 DATABASE_ERROR`)用在证据**指名**了存储故障的地方(驱动的 missing-relation
+  措辞、`looksLikeInternalErrorLeak` 命中);而这一支的定义性事实是「没有任何证据」,
+  把处理器的 `TypeError` 报成 `DATABASE_ERROR` 会把运维指向一个其实健康的数据库。
+  `INTERNAL_ERROR` 是 `standardErrorCodeForHttpStatus(500)` 的取值
+  (`@objectstack/spec` 的 `HttpStatusErrorCodeMap`)——目录自己为「500 且无更具体
+  code」定义的下限,不是第三套措辞;message 复用的也是
+  `resolveErrorResponse` 声明式 5xx 分支已在用的 `INTERNAL_ERROR_MESSAGE`。
+
+  **如果你的客户端把这条兜底当 400 处理过**:它现在是 5xx,可以重试;若你有生产者
+  依赖「不声明 status 即可把 message 原文送达调用方」,请改为在抛出点声明
+  `status` 与 `code`(契约优先),那是唯一仍会把措辞交给调用方的路径。
+
+- 2d25303: fix(rest): 联合类型分支里的拒绝理由现在能到达调用方,不再只剩 `Invalid input` (#5014)
+
+  zod 会把一个失配的 `z.union([...])` 折叠成**一条**顶层 `invalid_union` issue,它自己的
+  `message` 是裸的 `"Invalid input"`;每个分支真正的抱怨——包括 #4001 那批 `strictObject`
+  写下的处方文案——躺在 `issue.errors` 里(每分支一个数组)。`zodIssuesToFields` 过去只映射
+  顶层 issue,于是 `POST /api/v1/data/:object/query` 对着
+  `{"search": {"fields": ["name"]}}` 只回一条
+
+  ```
+  { "field": "query.search", "code": "invalid_shape", "message": "Invalid input" }
+  ```
+
+  ——说清「缺的是 `query` 这个键」的那句话被生产出来,然后被丢掉。同一个坑在
+  `QuerySchema.groupBy` 的联合分支上一样:`dateGranularity` 写错值,作者拿不到那份
+  「可选 day/week/month/quarter/year」的清单。
+
+  现在 `fields[]` 会在联合条目**之后**追加解释它的分支条目,`field` 用分支路径拼上联合自身
+  的路径(`query.search.query`),`code` 照常走 ADR-0114 D3 的目录映射——所以缺键报
+  `required` 而不是 `invalid_type`(这一判定要走绝对路径去读入参,分支路径是相对的)。
+
+  分支选择策略直接沿用 #4971 给 CLI/spec 侧 `formatZodError` 落的那一套:只报根部
+  KIND 不匹配的分支整支丢弃(全部如此则不展开,输出和以前逐字一致);剩下的**报得最少的
+  分支胜出**——这条是防止「一个拼错的键被 N 个分支各报一遍」的机制本身;`unrecognized_keys`
+  破平局;声明顺序破剩下的;真正并列的分支全部输出(上限 3 条);跨分支重复的相同结论只
+  出现一次;嵌套联合按绝对路径递归,深度上限 3。两侧必须给出**同一个判定**,否则同一个错误
+  从终端发布和从 API 提交会得到两套说法。
+
+  对 wire 而言这是**纯追加**:原有的每一条 `fields[]` 条目——包括联合自身那条——`field` /
+  `code` / `message` 和相对次序都不变,新条目插在它解释的那条之后。信封形状仍与
+  `mapDataError` 同形(ADR-0114),数组长度从来不是契约的一部分。
+
+- 1216dcc: fix(rest): sweep the REST composition root's slot lookups — 16 sites typed (#4251 B4)
+
+  Batch B4 of the #4251 sweep: every service-lookup erasure in the REST
+  composition root. `rest-api-plugin.ts` (15) and `external-datasource-routes.ts`
+  (1) now pass the slot's contract type instead of annotating the result `any`;
+  the ratchet baseline drops **159 → 143 sites, 34 → 32 files**, and both files
+  leave the grandfather list. No behaviour change.
+
+  **Every contract named here is evidenced by an `implements`.** `email`,
+  `sharing`, `sharingRules`, `reports`, `approvals` and `external-datasource` had
+  a written `packages/spec` contract all along, and the class each provider
+  registers into the slot declares `implements` on it (`EmailService implements
+IEmailService`, `ExternalDatasourceService implements IExternalDatasourceService`,
+  …). So the compiler verifies the shape on the producer side on every build and
+  this file only has to name it — the #4404 discipline that replaced seven
+  unchecked local stand-ins with one checked claim. `auth`, `objectql`, `i18n`,
+  `analytics`, `security` and `metadata` come from the `ServiceSlotContracts`
+  ledger; `objectql` is `IObjectQLEngine`, not `IDataEngine`, because the consumer
+  reaches the full engine (the `transaction` probe behind the batch routes).
+
+  **The wrapper return annotations went with them.** Ten of these lookups sit
+  inside `async (environmentId?) => Promise<any | undefined>` providers, and
+  typing only the lookup would have re-erased the contract one line later — the
+  KNOWN RESIDUAL shape the rule documents and cannot see. Each provider now
+  returns its slot's contract.
+
+  **Three slots have no contract, and say so three different ways rather than one
+  `any`.** `env-registry` is typed as `RestEnvRegistry`, the shape `RestServer`'s
+  own constructor declares for that parameter, so the argument is checked rather
+  than waved through. `settings` gets a named local surface (`SettingsReadSurface`)
+  following B2's decision for this slot — `service-settings` is optional, so the
+  REST layer must not depend on it — carrying the one method the platform consumes
+  (`get`, through `resolveLocalizationContext`'s cascade) with the public
+  `ResolvedSettingValue` as its return type. `default-project` gets a narrow slice
+  declaring only the field this file reads. And the service-existence probe, whose
+  slot name is a runtime argument, is `unknown`: it asks whether something
+  occupies the slot and never touches its shape, which is exactly what `unknown`
+  says and `any` does not.
+
+  **No dead probe this batch — reported rather than implied.** Every earlier batch
+  in this line found one (#4361's `getMetaItem` on a service that never had it,
+  #4321's `registerInMemory`), so each probe the typed consumers make was checked
+  against its contract: `emailService.send`, `authService.getApi` /
+  `isAuthGateActive`, `svc.queryDataset`, `ql.transaction`, the six approval
+  verbs, the five security methods and the five federation methods all name real
+  members at real arities. The `external-datasource` route probes are now visibly
+  redundant-but-correct — the contract's methods are required, so `svc?.method` is
+  truthy whenever the service resolved, and the 503 path is reached only by the
+  service being absent, which is what it is for.
+
+  The new pin is a runtime test, deliberately. `packages/rest` excludes its test
+  files from `tsconfig.json` and declares no `typecheck` script, so no tsc program
+  compiles them and a type-level assertion there would evaluate never — the
+  phantom-check shape #5286 / #5449 paid for. What is checkable is the wiring, and
+  that is the risk this change actually carries: the providers are positional
+  arguments 6..19 of a twenty-argument constructor, all with the same
+  `(environmentId?) => Promise<unknown>` shape, so a provider resolving the wrong
+  slot is assignable everywhere and invisible to the compiler. The test drives
+  each provider and asserts it hands back the instance registered in ITS slot,
+  pins the exact set of slot names the boot resolves, and pins the degraded path
+  where every optional slot is empty.
+
+- 90fa077: fix(rest): a missing relation is only an unknown OBJECT when it IS the object asked for (#5462)
+
+  `mapDataError`'s unknown-object heuristic asked whether a driver error mentioned
+  `no such table` / `relation … does not exist` — never **which** table was
+  missing. A business object that was never registered and the metadata plane
+  collapsing entirely produce the same two words, so `sys_metadata` becoming
+  unreachable came back to the caller as:
+
+  ```
+  404 {"error":"Object not found","code":"OBJECT_NOT_FOUND"}
+  ```
+
+  The caller was told to check the object name they typed while the real answer
+  was "the metadata store is gone". And because 404 is an `isExpectedDataStatus`,
+  `handleRouteError` printed no `[REST] Unhandled error` — so a total outage of
+  the metadata plane left **not one line** in the server log. Reproduced in
+  process on a real `ObjectQL` + `ObjectStackProtocolImplementation` whose driver
+  fails every access with `SQLITE_ERROR: no such table: sys_metadata`:
+  `PUT /api/v1/meta/object/acct` answered 404 with zero log lines.
+
+  **The rule now: a missing-relation message is an unknown-object verdict only
+  when the relation it names is the object the request named.** Attribution takes
+  both halves — a request object, and a relation name the phrasing actually
+  carries (`no such table: main.acct`, `relation "public.acct" does not exist`;
+  the schema qualifier is stripped and the compare is case-insensitive). Prime
+  Directive #6 is what makes that comparison sound rather than a guess: the object
+  `name` **is** the table name, with no `tableName` mapping to launder it.
+
+  Anything unattributable — a different table than the one asked for, an auxiliary
+  table, no request object at all (which is every metadata / UI / discovery route,
+  since they call `handleRouteError(res, error)` without one), or a phrasing that
+  names no relation — is now the sanitised data-store fault the SQL-leak branch
+  has always emitted: `500 { "error": "Internal data error", "code":
+"DATABASE_ERROR" }`. 500 sits outside `isExpectedDataStatus`, which is what buys
+  back the log line the silent 404 never had; the driver's own words still never
+  reach the client.
+
+  Deliberately unchanged:
+
+  - **A genuine unknown object is still a quiet `404 OBJECT_NOT_FOUND`.** Both
+    producers still land on one envelope (#3770): the protocol's registry gate,
+    and the driver limb when the missing table is the requested object. It still
+    logs nothing — an unknown object is a client mistake, not a fault (#4886).
+  - **The engine-authored limbs.** `unknown object`, `object not found`,
+    `[ObjectQL] No driver available for object '<name>'` and the quoted-name
+    catch-all are ObjectStack's own vocabulary about a named object; they mean
+    what they say. Only the DATABASE-authored limbs, which cannot know which table
+    the caller wanted, needed attribution.
+  - **The declared-status band.** #5437/#5464 (a declared 5xx is withheld and
+    logged) and #5423/#5436 (a 4xx is truncated, not erased) answer in
+    `resolveErrorResponse` before the heuristic is reached at all. That fix
+    covered producers that declare `status: 500`; this path never reached it,
+    because `saveMetaItem` rethrows the driver's `Error` with no `status` and no
+    `code` — which is why the message text was judging it.
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [64cd010]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [b746aa0]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [08f93bc]
+- Updated dependencies [d9971d3]
+- Updated dependencies [eb3e650]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [02dc076]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [e98fb14]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [1b9a53b]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [46365ab]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [c5adfe1]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [f104bab]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/types@17.0.0-rc.4
+  - @objectstack/core@17.0.0-rc.4
+  - @objectstack/platform-objects@17.0.0-rc.4
+  - @objectstack/observability@17.0.0-rc.4
+  - @objectstack/service-package@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Minor Changes
diff --git a/packages/rest/package.json b/packages/rest/package.json
index 1c7f41dde4..f2e37b33d6 100644
--- a/packages/rest/package.json
+++ b/packages/rest/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/rest",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "ObjectStack REST API Server - automatic REST endpoint generation from protocol",
   "type": "module",
diff --git a/packages/runtime/CHANGELOG.md b/packages/runtime/CHANGELOG.md
index 140f9fd9d5..15ae3311e5 100644
--- a/packages/runtime/CHANGELOG.md
+++ b/packages/runtime/CHANGELOG.md
@@ -1,5 +1,1567 @@
 # @objectstack/runtime
 
+## 17.0.0-rc.4
+
+### Major Changes
+
+- 739f496: feat(runtime)!: action body `ctx.session` emits `positions` (canonical) alongside the deprecated `roles` (#5613)
+
+  `buildActionSession()` — the one producer of the action-body `ctx.session` — now
+  emits the caller's position names under **both** `positions` (canonical) and
+  `roles` (deprecated alias), with the same array under both names. This is the
+  **runtime half** of #5613 phase 2 under the maintainer's contract-first ruling
+  ("C skeleton + A semantics"); the spec half (#5779) declared the shape this now
+  produces, and phase 1 (#5697) declared the shape it produced before.
+
+  **What was wrong.** The builder copied `ExecutionContext.positions` into a key
+  spelled `roles` — the one spelling ADR-0090 D3 bans — while its own docblock
+  claimed it "mirrors the hook `ctx.session` shape". That sentence stopped being
+  true at #5050, which retired `HookContext.session.roles` outright: a body author
+  met two different answers to one key name on one platform, and the comment
+  pointed at the wrong one. The key set reached no schema and no gate until #5697,
+  so nothing could see it drift.
+
+  **Migration prescription — do this now.**
+
+  - Read `ctx.session.positions`. It carries exactly the array `ctx.session.roles`
+    carried (`ExecutionContext.positions` — the rename is a rename, not a semantic
+    change), and it is the spelling the platform now uses everywhere: the
+    execution context, the sharing service, `ctx.user.positions`, and the hook
+    `ctx.session.positions` (#5605).
+  - `ctx.session.roles` still resolves for the length of the deprecation window
+    announced by the ADR-0087 semantic migration
+    `action-session-roles-to-positions`, and is then removed on the path
+    `session.tenantId` already walked (#3280 deprecated → #3290 removed in v11). A
+    body still reading it at that point sees `undefined` with nothing to catch the
+    change — which is why the read moves **inside** the window, not at its close.
+  - Do **not** migrate an access check by renaming it. `roles.includes('admin')`
+    rewritten as `positions.includes('admin')` migrates the defect: neither array
+    is an authorization input. Privilege is judged by the security service, which
+    evaluates capability grants, placements and the derived posture (ADR-0095).
+  - Presence semantics are unchanged: a context with no positions (or a non-array
+    `positions`) yields **neither** key — `'positions' in ctx.session` answers
+    `false` exactly when `'roles' in ctx.session` does — and a call with no
+    identity envelope still yields no session at all rather than `{}` (#3712).
+
+  **Also breaking, for TypeScript consumers of the sandbox seam.**
+  `ScriptContext.session` (`@objectstack/runtime`, `sandbox/script-runner.ts`) was
+  `unknown` and is now the exported union `ScriptSession = ActionSession |
+HookContext['session']` — the two declared producer shapes this one seam
+  actually carries. Code that read an arbitrary property off it must now
+  discriminate the body kind (or read one of the keys both shapes declare:
+  `userId`, `organizationId`, `positions`). It is deliberately **not** narrowed to
+  `ActionSession` alone: the seam really does carry hook sessions, and declaring
+  otherwise would re-create the "one key, two realities" defect this change
+  closes.
+
+  The consistency between what the producer builds and what `ActionSessionSchema`
+  declares stays pinned in
+  `packages/runtime/src/action-session-shape-contract.test.ts`, and the observed
+  shape is verified through a real dispatch in `http-dispatcher.test.ts`.
+
+- 29c6c9d: feat(spec,core,runtime)!: declarative `apis:` refuses loudly instead of parsing into silence; the `ApiRegistry` family retires (#4936, #4939)
+
+  The declarative API-endpoint surface was **zero-execution end to end**, and said nothing
+  about it. Metadata loading worked perfectly — a stack declared `apis:`, `defineStack`
+  accepted it, and `GET /api/v1/meta/api` returned every endpoint with every key intact.
+  The execution side never fired once. On a real boot (showcase, 47 plugins) both declared
+  paths answered a bare `404 {"error":"Not found"}` — not even the dispatcher's semantic
+  404, because **no route was ever mounted** for a declared path, so the request died at
+  Hono's `notFound`. Behind that, the dispatcher's `handleApiEndpoint` branch resolved the
+  metadata service and called `matchEndpoint` on it — a method **no implementation in the
+  repo has ever provided**. The branch returned "not handled" on every request ever served.
+
+  So every key on `ApiEndpointSchema` was declared ≠ enforced: `path`/`method` (never
+  mounted), `type`/`target`/`objectParams` (never executed), `cacheTtl`,
+  `inputMapping`/`outputMapping`, `rateLimit`, `summary`/`description` — and
+  **`authRequired`**, a security semantic that parsed green and gated nothing at all. That
+  is false compliance, the failure ADR-0049 exists to stop, not debt.
+
+  ## BREAKING — a non-empty `apis:` is now rejected
+
+  Metadata that parsed cleanly before is now **refused at publish/validate**, with the
+  prescription in the rejection itself:
+
+  ```
+  apis: `apis:` (declarative ApiEndpoint) is DECLARED BUT NOT EXECUTABLE in this runtime,
+  so a non-empty array is rejected instead of silently accepted (#4936). …
+  ```
+
+  **FROM → TO.** `apis: [ …endpoints… ]` → `apis: []` (or delete the key; both are still
+  accepted, and an empty array is not a special case). To actually serve the route today,
+  mount it **in code** — a plugin manifest `contributes.routes` entry, or an `http.server`
+  route. That is now the only honest path, and the one `examples/app-showcase` uses
+  (`src/system/server/recalc-endpoint.ts`).
+
+  The refusal lives on `ObjectStackDefinitionSchema` itself, which is the single choke
+  point every path runs through — `defineStack`, the metadata plugin's artifact ingestion,
+  `os validate`, the lint scorer and `EnvironmentArtifactSchema`. There is no path that
+  forgot to check.
+
+  **The `ApiEndpoint` vocabulary is deliberately KEPT.** Retiring it was considered and
+  rejected: endpoint shapes are an industry-stable form, so a retirement would only mean
+  re-introducing the identical schema later. Your endpoint definitions stay valid TypeScript
+  and stay in the spec; only _authoring them into a stack_ is refused, and only until the
+  executor lands. Keep them commented next to your stack — that is what the showcase does.
+  The executor (route mounting + endpoint matching + per-key wiring for
+  `authRequired`/`cacheTtl`/`inputMapping`/`outputMapping`/`rateLimit`) is tracked by
+  **#5040**, which replaces this rejection with real execution.
+
+  ## BREAKING — the `ApiRegistry` / `ApiEndpointRegistration` family is removed (#4939)
+
+  The repo carried a **second**, unrelated declaration shape for "an API endpoint":
+  `ApiEndpointRegistrationSchema` and the ~500-line `ApiRegistry` service that
+  `createApiRegistryPlugin()` registered under `api-registry`. Nothing composed it — every
+  assembly site lived in `packages/core/examples/`, with no registration in
+  `packages/runtime`, `packages/cli` or any `examples/app-*`, and a real boot carried no
+  such service. The whole family was therefore inert, including
+  `ApiEndpointRegistration.requiredPermissions`, whose docs promised **in the present tense**
+  that "the gateway layer automatically validates these permissions" while no gateway read
+  it. Two declaration shapes, both dead; this retirement converges them on one.
+
+  Removed from `@objectstack/spec/api`: `ApiEndpointRegistration(Schema)`,
+  `ApiRegistry(Schema)`, `ApiRegistryEntry(Schema)`, `ApiMetadataSchema`,
+  `ApiParameterSchema`, `ApiResponseSchema`, `ApiDiscoveryQuerySchema`,
+  `ApiDiscoveryResponseSchema`, `ApiProtocolType`, `HttpStatusCode`,
+  `ObjectQLReferenceSchema`, `SchemaDefinition` (12 JSON-Schema defs, 67 authorable keys).
+  Removed from `@objectstack/core`: `ApiRegistry`, `createApiRegistryPlugin`.
+  Removed from `@objectstack/plugin-hono-server`: the `useApiRegistry` option — it was
+  defaulted to `true` and read by nothing, configuring a service that was never composed.
+
+  **FROM → TO.** There is no replacement shape to migrate to, because nothing executed the
+  old one: delete the registration objects. If you were assembling an `ApiRegistryEntry`,
+  you were building a value only your own code read — keep it as your own type. Declarative
+  endpoints have one vocabulary now, `ApiEndpointSchema`.
+
+  `ConflictResolutionStrategy` **survives** the removal and moved to
+  `@objectstack/spec/api`'s `router.zod` — same name, same four values
+  (`error`/`priority`/`first-wins`/`last-wins`), same import path. It is pinned there by two
+  independent ratchets and is not part of the retired surface.
+
+  ## Also in this change
+
+  - **BREAKING (`@objectstack/runtime`):** `HttpDispatcher.handleApiEndpoint()` is deleted,
+    along with its now-orphaned private `callData` delegate, and `/__api-endpoint` leaves
+    `LEGACY_CHAIN_PREFIXES` and the route ledger. The method was public, so this is an API
+    removal — but it returned `{ handled: false }` for every call it ever received, so no
+    caller can observe a behaviour change beyond the missing symbol. Delete the call.
+    Absence is now loud (ADR-0076): the surface is refused at authoring rather than 404ing
+    at runtime with dead code behind it.
+  - `examples/app-showcase` no longer declares endpoints, and its coverage manifest no
+    longer claims the capability is `demonstrated` — that entry read "executed by the runtime
+    dispatcher (handleApiEndpoint)", which was exactly the advertise-what-you-don't-deliver
+    claim Prime Directive #10 forbids.
+  - The endpoint-level `rateLimit` tracking pointers left by #4910/#5006 now name **#5040**,
+    the live executor card, instead of #4936, which closes with this change.
+
+- d9cac60: **BREAKING** — `GET /meta/:type/:name` now answers exactly one body shape: the
+  `GetMetaItemResponseSchema` envelope `{ type, name, item, … }` that
+  `packages/spec` has always declared for it. On the default configuration this
+  endpoint used to answer the **bare metadata document** instead (#5563).
+
+  ### What changed, and why it is breaking
+
+  The route had two mutually exclusive branches with different response
+  structures. The cached branch — reached whenever `metadata.enableCache` is on,
+  which is the **default** (`enableCache: z.boolean().default(true)`) — served
+  `getMetaItemCached`'s `result.data`, and that value has the envelope already
+  stripped. The uncached branch served `getMetaItem`'s envelope. So the one shape
+  the spec declared was the one a default deployment could not obtain, and the
+  envelope surfaced only when the cache was off or when the read structurally
+  bypassed it (`app`, `doc`, `book`, `?state=draft`, `?preview=draft`,
+  `?package=`). Consumers had no correct static type — they sniffed at runtime or
+  reached for `as any` (#5545 was blocked on exactly this).
+
+  The dispatcher's `/meta` domain had the same split one layer down: the protocol
+  resolver answered the envelope while the ObjectQL-registry and MetadataService
+  fallbacks answered bare documents. Both fallbacks now wrap what they found,
+  taking `type`/`name` from the request.
+
+  ### Migration
+
+  `GET /api/v1/meta/object/customer`, default configuration:
+
+  ```jsonc
+  // before — the bare document
+  { "name": "customer", "label": "Customer", "fields": { /* … */ } }
+
+  // after — the declared envelope; the document is verbatim under `item`
+  {
+    "type": "object",
+    "name": "customer",
+    "item": { "name": "customer", "label": "Customer", "fields": { /* … */ } }
+  }
+  ```
+
+  - **Reading the body directly** (`fetch`, `client.meta.getItem`,
+    `client.meta.getCached().data`): read the document at `.item`. Nothing inside
+    it changed. `type` is the canonical singular metadata type name, so
+    `/meta/objects/customer` and `/meta/object/customer` answer the same `type`.
+  - **`useObject` / `useFields` (`@objectstack/client-react`)**: `useObject().data`
+    is now the envelope — `data.item.label`, `data.item.fields`, where it used to
+    be `data.label` / `data.fields`. `useFields()` is unchanged (it already
+    returns the flattened field list) and is the shorter path when fields are all
+    you need.
+  - **`isMetaEnvelope`, exported from `@objectstack/rest`, is REMOVED.** It
+    existed only to tell the two shapes apart. There is one shape now, so the
+    replacement for `isMetaEnvelope(r) ? r.item : r` is `r.item`.
+  - **Not converged, deliberately**: `?layers=true` still answers the layered
+    diagnostic projection `{ type, name, code, overlay, overlayScope, effective,
+validation }`. Collapsing three layers into one `item` would delete the
+    diagnostic. Unaffected unless you pass that flag.
+
+- 0cd08d5: refactor(runtime)!: retire the exported `HttpServer` delegating wrapper — it declared `implements IHttpServer` and forwarded none of the contract's optional members (#5122)
+
+  **BREAKING.** `@objectstack/runtime` no longer exports `HttpServer`, and
+  `packages/runtime/src/http-server.ts` is deleted.
+
+  ## What it was, and why it could not stay
+
+  The class took an `IHttpServer` in its constructor and forwarded that server's
+  **required** members — `get` / `post` / `put` / `delete` / `patch` / `use` /
+  `listen` / `close` — while declaring `implements IHttpServer`. It forwarded not
+  one of the contract's **optional** members:
+
+  | Optional member         | What wrapping it cost                                                                                                                        |
+  | ----------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- |
+  | `getPort?()`            | the real bound port after `listen(0)`; harnesses and `@objectstack/http-conformance` address the server through it                           |
+  | `getRawApp?()`          | the framework-native escape hatch four consumers feature-detect (cloud-connection ×2, metadata's HMR routes, cloud's serverless node server) |
+  | `setFallbackHandler?()` | since #5111, the **only** entry path there is for declarative `apis:` endpoints                                                              |
+
+  `packages/spec/src/contracts/http-server.ts` tells consumers to feature-detect
+  those members with `typeof server.X === 'function'` and to degrade when they are
+  absent. Wrapping a capable adapter therefore made every probe answer **false**
+  and the capability disappear — with the adapter underneath providing it the
+  whole time. Write this row down before reaching for a wrapper of the same shape:
+  **a host that wrapped `HonoHttpServer` and registered the wrapper as
+  `http.server` would answer 404 to every endpoint its metadata declared**,
+  because the seam those endpoints mount through was never forwarded. The dispatcher's
+  own #5409 declaration — the seam's absence announced at `warn`, welded by
+  `packages/runtime/src/dispatcher-plugin.fallback-absence-warn.test.ts` — remains
+  the runtime-side backstop and still fires here, but it can only name the missing
+  seam; it cannot name the wrapper that swallowed it.
+
+  ## Migration
+
+  **Register an `IHttpServer` adapter INSTANCE, don't wrap one.** Every real host
+  in this repository already does; `new HttpServer(` had zero occurrences in the
+  repository, examples included, which is why this retirement carries no rollback
+  risk and why it is cheaper to take now than later.
+
+  | Wrote                                                                  | Write instead                                                                                                                                                                                  |
+  | ---------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+  | `new HttpServer(new HonoHttpServer(port))` registered as `http.server` | register the `HonoHttpServer` (or your own adapter) directly — `HonoServerPlugin` already does                                                                                                 |
+  | a wrapper of your own to add cross-cutting behaviour                   | forward **every** member you did not deliberately drop, optional ones included, and re-probe with `typeof` after wrapping; a delegator that narrows the contract silently removes capabilities |
+  | `import { HttpServer } from '@objectstack/runtime'`                    | remove it — `tsc` reports this one, the symbol is simply gone                                                                                                                                  |
+
+  Unlike a method quietly dropped from a class, this break is visible to the
+  compiler: the export does not exist, so nothing type-checks past it. Its absence
+  from the barrel is additionally pinned at runtime by
+  `packages/runtime/src/http-server-retirement.test.ts`.
+
+  ## Why retirement rather than conditional forwarding
+
+  Growing a forwarding surface nobody composes would have to be maintained forever
+  and re-audited every time `IHttpServer` gains an optional member — it gained one
+  as recently as #5080. The 2026-08-06 maintainer ruling took the #4939
+  (`ApiRegistry`) precedent instead — retiring a part that was never assembled
+  beats repairing it — under ADR-0049's remove side.
+
+- dca5bd3: **BREAKING**: `ctx.user.roles` 已移除 —— action body / AI 路由处理器上的调用者位置(positions)只保留一个拼法 `ctx.user.positions`(#6011)
+
+  `ActorUser`(action body 的 `ctx.user`、AI 路由处理器的 `req.user`)过去同时发出两个键,值完全相同(`roles` 是 `positions` 的逐字副本)。`roles` 是 ADR-0090 D3 明令保留并禁用的词,且没有关闭日期 —— 维护者 2026-08-06 裁定**立即退役**,不设弃用窗口、不双发。
+
+  ### 迁移:FROM → TO
+
+  ```js
+  // FROM — v17 起该键不再存在,读到的是 undefined
+  const positions = ctx.user.roles;
+  if (ctx.user.roles.includes('sales_rep')) { … }
+
+  // TO — 权威拼法,值逐字不变
+  const positions = ctx.user.positions;
+  if (ctx.user.positions.includes('sales_rep')) { … }
+  ```
+
+  一行修复:把 body / 路由处理器里的 `ctx.user.roles` 改写成 `ctx.user.positions`(`req.user.roles` → `req.user.positions`)。**值不变** —— 两个键此前由同一次赋值产生,所以这是一次纯粹的改键,不是改语义。`positions` 数组恒存在,空时是 `[]` 而非 `undefined`,无需 `?? []`。
+
+  ### ⚠️ 改键不等于修好了权限判断
+
+  `positions` 与此前的 `roles` 一样,**都不是授权输入**。权限由 security service 判定(capability 授予、placement、ADR-0095 推导出的 posture),不由名字字符串比较判定。因此:
+
+  ```js
+  // 这不是迁移,这是把缺陷换了个拼法
+  if (ctx.user.roles.includes('admin')) { … }      // 旧的错
+  if (ctx.user.positions.includes('admin')) { … }  // 一样错,只是改了键名
+  ```
+
+  把 `roles.includes('admin')` 改写成 `positions.includes('admin')` 迁移的是**缺陷本身**,不是那次读取。这类判断应改为向 security service 询问能力,而不是比对位置名。(与 #5991 的 `ctx.session` 更名同一告诫。)
+
+  ### 不受影响的面
+
+  - **`ctx.session.roles` 不在本次范围内**,仍按 #5613 的弃用窗口双发 `positions` + `roles`,由 ADR-0087 语义迁移 `action-session-roles-to-positions` 约定其关闭时点。两个面同名不同物,请勿混为一谈。
+  - better-auth 会话上的 `user.roles`、`/api/v1/auth/me/permissions` 返回体的 `roles`、CEL/formula 的 `current_user.*`,都是各自独立的生产者,均未改动。
+
+### Minor Changes
+
+- 64cd010: fix(runtime,types)!: `/analytics/query` no longer echoes RLS policy field names — the declared-server-fault withhold is shared by both HTTP boundaries (#5811)
+
+  **Observable behaviour change — read this if you read, log, or assert on
+  `error.message` from a dispatcher-plugin route.** An error that **declares a
+  server fault** in the ADR-0112 envelope (`status >= 500` _and_ a non-empty
+  `code`) now leaves `dispatcher-plugin.errorResponseBase` with its message
+  replaced by `"Internal server error"`. It previously reached the caller verbatim
+  unless it happened to _sound_ like a SQL/driver dump. This applies to every route
+  that plugin mounts — `/analytics`, `/packages`, `/i18n`, `/automation`, `/auth`,
+  `/notifications`, `/mcp`, … — not only the one that motivated it. Nothing a
+  machine reads changed: the producer's `code` still arrives in the response
+  (`error.code`, promoted there from `details` by the shared envelope builder,
+  #3842), the status is untouched, and the full original text still goes to the
+  server log and `errorReporter` via `__obsRecordedError`.
+
+  ## What was wrong
+
+  #5367 (maintainer ruling 2026-08-06) made `read-scope-sql.ts`'s ten fail-closed
+  RLS lowering refusals `READ_SCOPE_COMPILE_FAILED` / 500 and taught
+  `POST /analytics/dataset/query` to withhold their message, because those messages
+  name the field names and comparands of an **administrator's** sharing rule:
+
+  ```
+  [read-scope-sql] unsafe field identifier "secret_policy_field" — refusing to
+  build read scope (fail-closed).
+  ```
+
+  The caller never wrote that field name and must not be able to read it out of an
+  error body. But the **sibling** analytics face was never closed.
+  `compileScopedFilterToSql` runs on both `NativeSQLStrategy.applyReadScope` and
+  `ObjectQLStrategy`'s echoed SQL, both of which serve `POST /analytics/query`,
+  which exits through `dispatcher-plugin.errorResponseBase`. That exit's only
+  message guard was `looksLikeInternalErrorLeak` — a heuristic over SQL/driver
+  _phrasing_ — and all eleven read-scope message shapes return `false` from it.
+  Measured at that boundary: **11 of 11 echoed verbatim**, at 500, with the policy
+  content in `error.message`. A real reachable disclosure, not a theoretical one.
+
+  ## What changed
+
+  - **`@objectstack/types` gains `declaresServerFault(err)`**, exported from
+    `error-leak.ts` beside `looksLikeInternalErrorLeak`. The heuristic asks whether
+    a message _sounds_ internal; the declaration asks whether the producer _said
+    so_. `error-leak.ts`'s own file header already states the principle — "do not
+    ship driver internals to clients" is a property of the HTTP boundary, not of
+    one router — and this is the second predicate that principle asks for.
+  - **Both boundaries read it.** `dispatcher-plugin.errorResponseBase` gains the
+    withhold (the fix); `rest-server.ts`'s `/analytics/dataset/query` catch drops
+    its in-line copy of the same test in favour of the shared one. #5808 wrote that
+    rule in-line on purpose — promoting a rule with one consumer is a speculative
+    surface — and this is the second consumer, so it was promoted rather than
+    duplicated (`#3843`/`#3867` paid for the two-implementations shape twice).
+    The REST face's verdict is unchanged in every case: same `status >= 500` plus
+    non-empty `code` test, over the same two fields.
+
+  ## What deliberately did NOT change
+
+  - ⛔ **This is not "withhold every 5xx".** #5667 kept **undeclared** 5xx errors
+    legible on purpose: a bare `Error` from our own code ("no strategy can handle
+    query …") is the operator's own bug report, names nothing tenant-sensitive, and
+    still falls to `looksLikeInternalErrorLeak` alone. A 5xx carrying only half an
+    envelope (a status with no code) is likewise still readable — inventing the
+    withhold for it would be the consumer-side leniency Prime Directive #12 removes.
+  - **4xx is untouched.** `declaresServerFault` requires `status >= 500`, so a
+    deliberate business/validation answer can never be swallowed by it.
+  - **`statusCode` is not accepted as a substitute for `status`.** `status` is the
+    channel ADR-0112 declares; making a disclosure rule depend on which spelling a
+    producer reached for would be the same leniency in a different place.
+  - **The heuristic was not taught to recognise `[read-scope-sql]`.** That would be
+    more prose sniffing — the mechanism #5352/#5367 exist to remove — and would only
+    ever cover the family someone remembered to add.
+
+  Coverage: `analytics-query-read-scope-withhold.test.ts` (runtime) drives six RLS
+  policy shapes end-to-end through a **real** `AnalyticsService` on the real
+  native-SQL path and the real mounted route, asserting the 500, that the whole
+  serialized body contains no policy detail, that `error.code` still carries
+  `READ_SCOPE_COMPILE_FAILED`, and that the full text is still on the
+  `__obsRecordedError` side-channel — plus a positive control and both sides of the
+  declared-vs-undeclared tiering. `error-leak.test.ts` (types) pins the predicate
+  directly, including that all eleven read-scope shapes stay invisible to the
+  heuristic. The REST face's existing `analytics-read-scope-refusal-envelope.test.ts`
+  is green before and after, unchanged, which is the pin on the refactor.
+
+- db9c331: fix(runtime,cli): 未设置 `NODE_ENV` 时 `/discovery` 不再自称 `development`,统一按 `production` 解读 (#5673)
+
+  同一个「宿主没有设置 `NODE_ENV`」的事实,仓里原本有两套相反的默认:`os start` 未设时强制
+  `NODE_ENV='production'`(`start.ts:248`),`os serve` 与 `os doctor` 按
+  `NODE_ENV || 'production'` 解析 `.env*` 级联,而 `/discovery` 的 `environment` 字段
+  直接把缺省读成 `development`。
+
+  **为什么这个方向的错报是危险的那个。** `environment` 是**机器可读面**上的字段,客户端
+  拿它回答「我在不在生产环境」,并可能据此不显示生产警示、放宽破坏性操作的二次确认。一个
+  忘记设 `NODE_ENV` 的真实生产部署,过去会拿到 `development` —— 两种错法里代价更高的那种。
+  按 maintainer 2026-08-06 裁定,缺省统一收敛到保守值 `production`。
+
+  **迁移说明(行为变更,请对照自己的部署方式读)**
+
+  - **生产部署忘设 `NODE_ENV`**:`/discovery` 的 `environment` 由 `development` 变为
+    `production`。这正是本次修复的目标 —— 报的是实情,不需要任何动作。
+  - **本地开发**:不受影响。`os dev` 会 spawn `serve --dev`,而 `serve` 在 `--dev` 且
+    `NODE_ENV` 未设时就地设 `NODE_ENV='development'`(`serve.ts:490-491`),所以
+    `pnpm dev` / `pnpm dev:showcase` / `dev:crm` / `dev:todo` 链路上 `NODE_ENV` 早已是
+    显式的 `development`,`/discovery` 仍报 `development`。没有任何脚本因此改动。
+  - **需要 `development` 却不走 `os dev` 的场景**(裸 `os serve`、以库形式内嵌运行时、
+    自建容器入口):现在必须显式 `NODE_ENV=development`。这是本次唯一需要动手的一类。
+  - **已设置的合法拼法一律不变**:`production`/`prod` → `production`,
+    `staging`/`sandbox` → `sandbox`,`development`/`dev`/`test` → `development`。
+  - **无法识别的拼法处置不回退**:`qa`、`preview`、`uat` 这类**设了但认不出**的值仍然
+    降级为 `development`,#4828 的「绝不凭猜测宣称 production」保持原样。缺省不是猜测,
+    是宿主选择不说 —— 两条是不同的规则,本次只动前者。
+
+  **`os doctor` 新增一行提示。** `NODE_ENV` 未设时报
+  `NODE_ENV  Not set — this environment is being treated as production`(warning,不影响
+  退出码),`--verbose` 展开显式设置的两条命令。已设置的环境完全没有这一行,报告与从前
+  逐字一致。统一默认让缺省变得**安全**,但也让「疏忽」和「有意的生产部署」变得无法区分;
+  这一行是唯一能把两者分开的地方。
+
+  **已知残留(已另开 #5936 跟进,本次不动)。** `/discovery` 有两个生产者。本次改的是
+  `@objectstack/runtime` 的 `HttpDispatcher.getDiscoveryInfo()`;经 `@objectstack/rest`
+  暴露的 `MetadataProtocol.getDiscovery()`(`packages/metadata-protocol`)把真实缺省原样
+  递给共享映射函数,该函数对缺省仍返回 `development`。裁定把落点限定在 runtime 侧、把
+  `packages/metadata-protocol` 标为跨域文件面,所以此处如实记录而非顺手绕过。
+
+- 77022a9: feat(spec,runtime,metadata-protocol)!: one schema for both discovery producers — `capabilities` canonical, `features`/`endpoints` retired, `scoping` declared (#4828)
+
+  `/discovery` is a machine-readable surface, but nothing compared what the two
+  producers emit against what `packages/spec` declares. The only schema the
+  protocol layer referenced was `GetDiscoveryResponseSchema` —
+  `DiscoverySchema.partial().required({version}).extend({apiName})` — so
+  `.partial()` hid every missing REQUIRED key while zod's default unknown-key
+  strip hid every UNDECLARED emitted one. The two producers then drifted in
+  opposite directions through the same blind spot.
+
+  `DiscoverySchema` is now authoritative for producers, and each producer package
+  carries a `discovery-schema-conformance.test.ts` that parses its LIVE shape
+  against it and checks its emitted key set against the protocol schema's shape.
+
+  **Breaking for anyone reading the dispatcher's `/.well-known/objectstack` body:**
+
+  - `features` → **`capabilities`**, the name `DiscoverySchema` has always
+    declared, in the declared `{ enabled }` shape. The same flags survive. This
+    fixes a real defect: the SDK's `client.capabilities` getter reads
+    `discoveryInfo.capabilities`, so against a dispatcher-served host it returned
+    `undefined` for every flag while the answers sat one key away under `features`.
+  - `endpoints` — **removed**. It duplicated `routes` verbatim as a
+    "backward compatibility" alias; a consumer census across `objectstack`,
+    `objectui` and `cloud` found no reader. Use `routes`.
+  - `environment` is now **mapped** into its declared enum instead of passing
+    `NODE_ENV` through raw (`test` → `development`, `staging` → `sandbox`,
+    unrecognized → `development`, never `production` on a guess). `NODE_ENV=test`
+    and `staging` previously advertised values outside the declared enum.
+
+  **Additive elsewhere:**
+
+  - `DiscoverySchema` declares `scoping` (optional) — the environment-scoping
+    posture the REST endpoint has always emitted and `packages/client` has always
+    consumed, now part of the contract instead of an undeclared extra.
+  - The REST `/discovery` body gains the required `name` / `environment` /
+    `locale`, so it can satisfy `DiscoverySchema` at all. `locale` is derived from
+    the registered i18n service, the same way the dispatcher derives it.
+  - `name` is canonical on both producers. `apiName` remains as a deprecated alias
+    carrying the identical value and is **scheduled for removal in protocol 18**.
+  - New exports: `DiscoveryEnvironmentSchema`, `DiscoveryEnvironment`,
+    `resolveDiscoveryEnvironment`.
+
+- fd8521f: fix(runtime): the HTTP dispatcher serves each request from its OWN resolved kernel — two tenants can no longer swap data sources under each other (#5155)
+
+  A host constructs exactly **one** `HttpDispatcher` (`dispatcher-plugin.ts`
+  `start()`), and every route it serves shares that instance. The kernel a request
+  resolves to, however, is per request: on a multi-tenant host the injected
+  `kernelResolver` (ADR-0006) picks a different one per environment.
+
+  That per-request answer was being stored on a dispatcher **instance field**,
+  `this.kernel`, written once per request by `resolveRequestScope()` and then read
+  by `resolveService()` / `getService()` / `getObjectQL()` /
+  `getRequestKernelService()` / `announceKernelEvent()` / `getRegisteredAiRoutes()`
+  — every one of them behind at least one `await`. Node's single thread is no
+  protection here: what it protects is code that does **not** hold mutable shared
+  state across an `await`, and this held it across several.
+
+  So two interleaved requests on two environments produced this:
+
+  1. request A resolves, `this.kernel` = env-1's kernel;
+  2. A yields at an `await` (session lookup, driver query);
+  3. request B resolves, `this.kernel` = env-2's kernel;
+  4. A resumes and resolves `objectql` / `metadata` / `automation` off **env-2**.
+
+  One tenant's request reading another tenant's data source — a correctness and
+  isolation defect, not a performance one. Single-environment deployments were
+  never affected (`this.kernel === defaultKernel` always, so the write was
+  idempotent), which is exactly why no local run or CI job ever showed it. It is
+  now covered by a deterministic interleaving regression test
+  (`http-dispatcher.multi-tenant-concurrency.test.ts`), which fails on the old
+  code with request A being served env-2's data.
+
+  **The fix: the resolved kernel travels on the request, and every facility that
+  reads a kernel takes the request explicitly.** `HttpProtocolContext` gains a
+  `kernel` field, written by `resolveRequestScope()` alongside the
+  `environmentId` / `dataDriver` / `executionContext` it already writes there.
+  There is no longer any `this.kernel` to rewrite. An `AsyncLocalStorage` carrier
+  was deliberately **not** used: it would have reintroduced implicit mutable
+  ambient context, which is the shape of this bug in a new costume.
+
+  Three host-level readers moved to the host kernel explicitly, where they had
+  been reading whichever tenant resolved most recently: `/ready` (readiness is a
+  property of the replica), its driver-health probe, and the memoized
+  single-environment `default-project` lookup.
+
+  **Migration — `DomainHandlerDeps` and `ActionExecutionDeps`.** Every
+  kernel-reading member now takes the request as its **first** parameter. If you
+  implement or call either contract (both are exported from
+  `@objectstack/runtime`; nothing in this monorepo or the sibling distributions
+  did):
+
+  - `deps.resolveService(name, envId)` becomes `deps.resolveService(context, name, envId)`
+  - `deps.getService(name)` becomes `deps.getService(context, name)`
+  - `deps.getObjectQL(envId)` becomes `deps.getObjectQL(context, envId)`
+  - `deps.getRequestKernelService(name)` becomes `deps.getRequestKernelService(context, name)`
+  - `deps.announceKernelEvent(event, payload)` becomes `deps.announceKernelEvent(context, event, payload)`
+  - `deps.getRegisteredAiRoutes()` becomes `deps.getRegisteredAiRoutes(context)`
+
+  `context` is the `HttpProtocolContext` the domain handler already receives. The
+  same rule applies to the `action-execution` helpers, which take it right after
+  `deps`: `callData`, `resolveAutomationService`, `dispatchFlowAction`,
+  `invokeBusinessAction`, `resolveRouteActionDeclaration`.
+
+  `HttpDispatcher.getDiscoveryInfo(prefix)` gains an **optional** second argument,
+  the request context. Callers that serve `/discovery` straight off the host (the
+  adapters, the dispatcher plugin) need no change and now describe the host kernel
+  deterministically instead of whichever tenant asked last.
+
+  `resolveProjectKernelObjectQL(context)` keeps its direct-caller kernel swap;
+  the swap is now written onto that context, so it stays visible to the rest of
+  that request and to nothing else.
+
+- 81e2744: 端点链接线:声明式 `apis:` 端点的派发步现在跑完整条链 —— 匹配 → 策略(`authRequired` / `rateLimit` / `cacheTtl`)→ 目标执行(`object_operation` 走 `/data` 同一个 `callData`,`flow` 走 automation 服务)。
+
+  兜底器(`dispatcher-plugin`)补齐三根一直缺的线:把完整的 `EndpointPolicyContext`(请求头、`remoteAddress`、与 server 级限流器同一个会话查询、每端点限流注册表、`trustProxy`)喂给派发步;把 `answer.headers` **写到线上**(此前 429 的 `Retry-After` 会被丢掉,客户端拿到一个不知道何时重试的 429);并在匹配前解析本请求的环境 / 身份(与 `dispatch()` 同一个 `HttpDispatcher.resolveRequestScope`),使委派调用带着调用方的 `ExecutionContext` 运行,而不是以 system 身份绕过 RLS。
+
+  `cacheTtl` 的 `Cache-Control` 只挂在**成功**答复上,任何错误答复都不带它。多租户 host 若无法把请求解析到某个环境,该步**弃权**(不写任何东西,保留传输层原本的 404),而不是拿默认 kernel 的数据来回答。
+
+  现网行为零变更:publish / validate 对非空 `apis:` 仍然硬拒(#5040 E7 前不撤),因此本链结构性不可达。
+
+- 277eb36: **声明式端点的执行目标委派:`endpoint-executor` 纯模块(#5040 E5)**
+
+  命中的 `apis:` 端点按 `type` 委派到**既有**执行管线,零新执行语义 —— 这是 #5040 §4 的裁决:声明式端点是既有管线的「稳定 URL 别名 + 策略层」,不是第二套执行方言;同一操作经声明端点与经内建路由必须得到一致的答案。
+
+  - `type: object_operation` → `action-execution.callData`,参数形状逐条对齐 `/data`(`find`→`('query', {object, query})`、`get`→`('get', {object, id, select?, expand?})`、`create`→`('create', {object, data})`、`update`→`('update', {object, id, data})`、`delete`→`('delete', {object, id})`)。记录 id 取 `query.id`(词表未定义路径模板,执行器不发明一套);`object` **只**来自声明,请求改不动它。身份信封(`executionContext`)在五个操作上一律透传 —— #4936 摘除的死代码正是丢了这个参数,真跑起来会以 system 身份绕过 RLS。
+  - `type: flow` → `IAutomationService.execute(target, buildAutomationContext(body, ctx))`,复用 `/automation` 触发路由**同一个**上下文构造函数(该函数因此从 `domains/automation.ts` 导出):`{recordId, objectName, params}` 翻译与完整身份信封转发一并继承,`runAs:'user'` 的流程不会 fail-closed 被拒(#3760)或以他人身份运行(#1888)。automation 槽为空或自称非 handler 时答 501,携带 discovery 同款处方句(ADR-0076 D12)。
+  - `type: script` / `proxy`,以及缺 `objectParams` 的 `object_operation`:结构化 **501 NOT_IMPLEMENTED**(带处方),不猜语义。这个「不支持子集」在模块里只列一处,供 E7 的 publish 门直接照读。
+  - 失败一律走既有错误包络:状态优先级与 `details` 组装照抄 `HttpDispatcher.errorFromThrown`(`.status` → `.statusCode` → 校验失败 400 → 兜底 500),5xx 消息过 `looksLikeInternalErrorLeak` 消毒(#3867/#3918)。新模块已加入 `error-envelope.conformance.test.ts` 的源码扫描名单。
+
+  **本次落地不接线**:调度步(`api-endpoint-step.ts`)命中后仍答 501,把它换成「策略 → 执行」链是随后的小型接线单(等 E4 #5091 一并落地);叠加 publish 对非空 `apis:` 的硬拒(E7 前不撤),该模块结构性不可达,现网行为零变更。
+
+- 41e605e: **声明式端点的映射键:`inputMapping` / `outputMapping` 链内应用(#5040 E5c)**
+
+  两个键此前被 `ApiEndpointSchema` 声明、被 runtime 读取零次:作者写了、publish 放行、端点跑起来映射什么也不做 —— 正是 #5040 要消灭的「解析通过然后什么也不发生」中间态,也是 ADR-0049 `declared ≠ enforced` 的教科书形状(对 AI 写的元数据尤其糟:静默忽略的键不产生任何信号)。新纯模块 `api-mapping.ts` 是它们的唯一读者,语义**只**来自冻结词表的 describe 文本,取其最小忠实解读:
+
+  - **`inputMapping`(_Map Request Body to Internal Params_)**:`source` 按点路径读**请求体**,投影出目标入参;在策略链通过之后、委派之前应用,因此映射永远买不通 `authRequired` / `rateLimit`,而 `endpoint-executor` 保持纯委派、对映射无感知。词表只说 body,**query 不并入**(合并会凭空发明一条谁覆盖谁的优先级规则),query 照旧原样抵达管线。
+  - **`outputMapping`(_Map Internal Result to Response Body_)**:只作用于**成功**答案的载荷(`{success, data, meta}` 的 `data`),包络逐字保留 —— 声明改不动 `success`,也就无法把失败装扮成数据。401 / 429 / 400 / 501 一律不重映射。
+  - **映射是投影,不是合并**:结果只由声明的 `target` 组成,未声明的字段不随行。出站方向因此天然是一份 allow-list —— `apis` 是平台的对外面(ADR-0121 D3),默认泄漏内部字段不是可接受的缺省。
+  - **`source` 解析不到 ⇒ `target` 不写**(映射是投影不是校验器);**无声明 ⇒ 逐字节直通、按引用原样传递**,未声明映射的端点与 E5b 的行为完全一致。
+  - **无法服务的声明响亮拒绝**,不静默跳过、不半应用:`transform`(全仓无「transformation function name」注册表,发明它是沙箱裁决而非映射细节)、不可用路径(空串、空段 `a..b`、`__proto__` / `prototype` / `constructor`)、互撞的 `target`(同路径或一个写进另一个内部)—— 均为结构化 **501 NOT_IMPLEMENTED**(带处方,点名具体条目如 `inputMapping[1].transform`),与 `endpoint-executor` 的 `unsupported` 分支同类同形。`outputMapping` 的这道判定在**委派之前**做:投影坏掉的 `create` 不该先插入记录再拒绝作答。
+  - 新模块已加入 `error-envelope.conformance.test.ts` 的源码扫描名单。
+
+  **现网行为零变更**:非空 `apis:` 在 publish / validate 仍被硬拒(E7 #5111 前不撤),整条端点链结构性不可达。上述「不支持子集」应由 E7 的 publish 门在作者写应用时就拒掉,本模块是运行期兜底,不是主关口。
+
+- 2649ccb: feat(runtime,hono): 挂载 seam —— `setFallbackHandler` 实现 + 声明式端点派发步(#5040 E3, #5090)
+
+  给声明式 `apis:` 端点铺上**唯一一条**能进入处理器的通路,并且这条通路在构造上不可能遮蔽任何
+  已注册路由。执行器本身尚未落地,本次改动**零现网行为变更**:任何 stack 目前都无法发布非空
+  `apis:`(publish 硬拒,直到 #5040 E7 翻转),所以这里新增的一切在真实组合里结构性不可达。
+
+  **`@objectstack/plugin-hono-server` —— `IHttpServer.setFallbackHandler` 的实现**
+
+  契约(#5080 落在 `@objectstack/spec/contracts`)的四条保证逐条兑现:
+
+  - 映射到 Hono 的 `app.notFound` 钩子,**不是**通配路由。这是全部要点:通配路由要与之后注册
+    的每一条路由竞争,而 Hono 按先注册者赢裁决,归属就变成插件 `start()` 顺序的函数 ——
+    ADR-0076 D11 正是为此存在。兜底器只在全部显式路由未命中后运行,**零注册顺序依赖**。
+  - handler 拿到的 `req.body` **可读**(与 `use()` 中间件 seam 相反,后者的契约明确不填充
+    body),按 content-type 解析,与真实路由处理器走同一段代码。
+  - 重复安装即**替换**,不成链。
+  - handler 不写响应 → 适配器既有的未命中答案(404,或方法不匹配时 405 + `Allow`)原样保留。
+
+  配套的一处属主收敛:404/405 应答此前由 `HonoServerPlugin.start()` 直接写在
+  `getRawApp().notFound(...)` 上。`app.notFound` 是后调用者覆盖,兜底 seam 落在同一个钩子上,
+  两个写入方意味着幸存者由插件启动顺序决定 —— 应答本体因此移入 `HonoHttpServer`
+  (`installNotFoundSeam()` / `setFallbackHandler()` 在其中组合),一个钩子一个属主。行为
+  逐字节不变(`notfound-405.test.ts` 原样通过)。
+
+  顺带修好同一段代码上的两处不一致:适配器构造的 `IHttpRequest` 现在一律带
+  `remoteAddress`(此前只有中间件 seam 有,同一个契约有两种形状);处理器**同步**抛出与
+  异步 reject 现在报同一种结果(此前同步抛出会逃到 Hono 自己的错误页)。
+
+  **`@objectstack/runtime` —— dispatcher 端点派发步**
+
+  dispatcher-plugin 在 `start()` 中探测 `typeof server.setFallbackHandler === 'function'`
+  并注册兜底器。对落在 ADR-0121 D1 保留段 `<prefix>/apps/<命名空间>/<子路径>` 下的请求,
+  探测 `metadata` 服务的 `matchEndpoint`(#5089 的实现在并行开发,探测缺席即穿透):
+
+  - **命中** → `501 NOT_IMPLEMENTED`,包络说明执行器随 17.x 落地(#5040 E4–E5 接策略键与
+    执行目标);
+  - **未命中 / 无 matcher / 无 metadata 服务 / 路径不在挂载前缀下** → **不写任何响应**,
+    传输层既有的 404/405 答案原样成立(有回归测试逐字节钉住);
+  - `matchEndpoint` 抛错按 5xx 出口应答,不降级为 404 —— 故障不得伪装成「没有这条路由」。
+
+  派发步**不重入** `dispatch()`:那条管线会解析环境与 `executionContext`、跑匿名拒绝门、并以
+  语义 404 收尾,把全部未命中请求灌进去会改变今天未命中请求的答案。裸 404 与语义 404 的收口
+  是另一个决定,本次刻意不做。
+
+  `route-ledger.ts` 新增 `* /apps/**` 登记行与 `NON_DISPATCH_MOUNT_PREFIXES`(本包在
+  `dispatch()` 之外挂载的前缀),注记如实描述已接线的部分与**尚未**接线的执行部分;新增
+  一致性测试钉住 ADR-0121 D1 赖以成立的事实 —— `/apps` 不属于任何内建域。
+
+- a70cd0a: 声明式端点的策略键接线:`authRequired` / `rateLimit` / `cacheTtl`(#5040 E4)
+
+  新增 `packages/runtime/src/endpoint-policy.ts` —— `ApiEndpointSchema` 三个策略键的唯一读取方,并接入端点派发步(匹配命中 → 策略链 → 答复)。三个键全部复用既有原语,零发明:
+
+  - `authRequired`:复用 `shouldDenyAnonymous` 与 `ANONYMOUS_DENY_*` 常量,未认证得到与 `/meta`、`/ai`、`/security` 完全相同的 401 包络。默认值由 schema 物化(缺省即 `true`),执行器读不到「未声明」这个中间态;`authRequired: false` 是唯一的开门方式,且在 diff 中可见。
+  - `rateLimit`:复用 #5006 的 `deriveBucketConfig` / `resolveRateLimitKey` / `SharedTokenBucketLimiter`,桶键为 `apiep:<端点名>:<主体或 IP>` —— 与 server 级预算各自独立计量,互不侵蚀。超限答与 server 级限流器逐字节一致的 429 + `Retry-After`。
+  - `cacheTtl`:仅响应头语义(不实现服务端缓存,#5091 已裁)。正值 → `Cache-Control: private, max-age=<ttl>`(`private` 是安全规则:任何响应都可能是按主体裁剪过的);`0`/负值 → `no-store`;缺省 → 不发头;非 GET → 不发头并 warn 点名。
+
+  链序按 #5040 §3:**先限流、后鉴权**、再算缓存头 —— 凭据爆破本就是匿名流量,先答 401 会让扫号者完全绕开计量。
+
+  **结构性不可达、零现网行为变更**:非空 `apis:` 在 publish/validate 仍被硬拒(E7 翻转前),且派发步在未获得策略上下文时的答复与此前逐字节相同。
+
+- 55dbbba: feat(spec,runtime,hono): `server.security.rateLimit` — an authored budget that actually returns 429 (#4910, #4937)
+
+  Rate limiting in ObjectStack was three shapes with nothing between them. `packages/spec`
+  declared `RateLimitConfig` in three places and the whole repo had **zero readers** for any
+  of them, so an author wrote a budget, it parsed, and nothing happened (#4686).
+  `@objectstack/runtime` shipped a token bucket whose comments claimed, in the present tense,
+  that the dispatcher called it and short-circuited with 429 — it had **zero call sites**
+  outside its own unit test, and the `DispatcherPluginConfig.rateLimit` field it told you to
+  tune did not exist (#4937). Neither half was broken; they were simply never connected, and
+  both were documented as if they were.
+
+  They are connected now, along one narrow path.
+
+  ## What you write
+
+  ```ts
+  export default defineStack({
+    manifest: {
+      /* … */
+    },
+    server: {
+      security: {
+        rateLimit: { enabled: true, windowMs: 60_000, maxRequests: 600 },
+      },
+      trustProxy: false,
+    },
+  });
+  ```
+
+  `server:` is a **new** top-level stack key. Nothing declared it before, so no existing
+  stack changes behaviour on upgrade — there is no configuration that was inert yesterday
+  and starts throttling today.
+
+  It is deliberately **narrow**: it carries `security.rateLimit` and `trustProxy` and
+  nothing else, because those are the two keys with a consumer. It is NOT the nine-key
+  `HttpServerConfigSchema` — the other seven have no reader and no authoring surface, and
+  mounting them here would have made seven dead keys writable in one move (their
+  enforce-or-remove fate stays with #4938). It is strict from birth (#4001), so a misspelled
+  budget is rejected with the correction rather than silently defaulted, and `maxRequests: 0`
+  is refused at `defineStack` rather than at 3am.
+
+  **No `server.port`.** The listening socket belongs to the deployment, not the artifact, and
+  `objectstack serve -p` already owns it. The precedence rule is recorded in the schema and
+  the docs in advance, so it cannot be re-litigated per caller: **CLI flag > `server:` >
+  built-in default.**
+
+  ## What happens
+
+  Every inbound request the server routes — REST, dispatcher, service routes, anything
+  mounted on that transport — consumes from a token bucket sized `capacity = maxRequests`,
+  refilling at `maxRequests / (windowMs / 1000)` per second. An empty bucket answers **429**
+  with a `Retry-After` computed from the bucket itself and the standard error envelope
+  (`code: "RATE_LIMIT_EXCEEDED"`). `OPTIONS` preflights are never metered.
+
+  The bucket is keyed by **resolved principal**, falling back to the caller's **IP** for
+  anonymous traffic — so one abusive session cannot spend another user's budget, and
+  credential-stuffing traffic (which has no principal yet) is still metered per source. That
+  IP comes from `X-Forwarded-For` / `X-Real-IP` **only when `trustProxy: true` is declared**;
+  otherwise it is the transport's own peer address. Undeclared, those headers are attacker
+  input: honouring them by default would hand anyone an unlimited supply of fresh buckets and
+  let them drain a chosen victim's.
+
+  Counters live in the kernel `cache` service when one is registered, so a multi-node
+  deployment enforces one budget instead of one per node (ADR-0069 D2), resolved lazily at
+  consume time so a cache plugin that registers later is still picked up (#4772). With no
+  cache service at all it falls back to a per-process store and says so once, naming the
+  consequence: the effective limit becomes the declared budget multiplied by the number of
+  nodes, and nothing about the deployment looks wrong.
+
+  ## Also in this change
+
+  - **`IHttpServer.use()` is a real middleware seam.** The Hono adapter's implementation
+    passed `{}` for both `req` and `res` and called `next()` unconditionally, so a registered
+    middleware could not read the request, write a response, or decline to continue — a
+    declared seam with no execution behind it, unnoticed because nothing called it. It now
+    delivers method/path/query/headers plus the transport peer address
+    (`IHttpRequest.remoteAddress`, new), and honours a short-circuit. Middleware must be
+    registered before the routes it guards; the kernel's two-phase boot makes that automatic
+    (`init()` before every `start()`).
+  - **`packages/runtime/src/security/rate-limit.ts` no longer describes an execution chain it
+    does not have** (#4937). The token-bucket arithmetic is extracted so the synchronous
+    in-process limiter and the new shared-store one cannot drift, and `DEFAULT_RATE_LIMITS` is
+    now labelled as the reference material it always was rather than as live defaults.
+
+  ## Explicitly NOT wired
+
+  `ApiEndpointSchema.rateLimit` and `ApiEndpointRegistrationSchema.rateLimit` remain
+  **known-unwired**. Declaring them still changes nothing. They are not retired here either:
+  the fate of the whole declarative `apis:` surface is undecided (#4936), and retiring one
+  key of a surface that may yet be implemented would only have to be undone. Tracked, not
+  silent.
+
+- ae490ef: feat(mcp): 开源发行版终于消费 skill —— `instructions` 半边投影为 MCP `prompts` 原语 (#3905)
+
+  `stack.zod.ts` 与 ADR-0063 §2 把 **skill 定为唯一第三方扩展原语**,而开源发行版
+  (BYO-AI,cloud ADR-0025)里零消费方:`SkillSchema` 可作者化、被两条 lint 规则认真
+  校验(`validateAiToolReferences` / `validateAiSurfaceAffinity`),却没有任何代码路径
+  读它 —— 作者写 skill → 校验通过 → lint 通过 → **永不运行且无人告知**。这正是本仓
+  ratchet 存在的意义所要消灭的 declared ≠ enforced 形状。
+
+  **skill 的两个半边,现在各自说清楚跑在哪。**
+
+  - **`instructions`(判断力)→ MCP `prompts` 原语,处处可用。** MCP 服务器补齐了
+    `prompts/list` / `prompts/get`:每个带 `instructions` 的已注册 skill 成为一个
+    MCP 客户端可以列出并取回的 prompt(prompt 名 = skill 机器名,`label` → `title`,
+    `description` 原样带上)。HTTP 与 stdio 两条传输都服务它。
+  - **`tools` / `surface` / `triggerConditions`(接线)→ 明确标注 cloud-runtime-only。**
+    绑工具与激活判定是 in-product agent 循环的属性;MCP 里模型在客户端、服务端只有
+    一张扁平工具表,AI 暴露的 Action 早已通过 `list_actions` / `run_action` 可达。
+    文档与 schema JSDoc 如实写明,不再装样子 —— 但两半边在两个发行版里都照旧接受
+    **校验**,所以开源里写的 skill 到 cloud 上语义完整,不必写两遍。
+
+  **协议合规。** `prompts` 能力按规范声明:只有当宿主能读到本环境的 skill 元数据时
+  才声明并注册处理器(能力协商如实,与 action 工具同一套优雅降级);无 skill 时
+  `prompts/list` 返回**空列表而非报错**;`prompts/get` 取不存在的名字返回
+  `-32602 InvalidParams`;没有 `instructions` 的 skill 与 `active: false` 的 skill
+  不投影。HTTP 面的投影从**本请求自己的 bridge** 读(与 `describeObject` 同一条
+  per-environment 通道),多租户宿主不会把一个环境的 skill 服务给另一个环境。
+
+  **同时修掉同仓重名。** `packages/mcp/src/skill.ts` 从来不是 skill 元数据类型,
+  而是 ADR-0036 Amendment C 的 `SKILL.md` 分发物 —— 在 `packages/mcp` 里 grep
+  `skill` 先找到的一直是它。现在按各自承载的产物命名:`skill-md.ts`(SKILL.md
+  分发物)与 `skill-prompts.ts`(skill 元数据 → prompts 投影),两侧模块头互指。
+  包的公开导出名(`renderSkillMarkdown` / `OBJECTSTACK_SKILL_NAME` /
+  `OBJECTSTACK_SKILL_DESCRIPTION` / `RenderSkillOptions`)一个未变。
+
+- aac90a5: feat(spec,runtime,metadata-protocol,client)!: one closed capability vocabulary — every discovery producer emits every key (#5672)
+
+  `#4828` renamed the runtime dispatcher's top-level `features` map to the
+  canonical `capabilities`, which collapsed the _spelling_ split between the two
+  discovery producers. It did not touch the deeper one: the two went on filling
+  **disjoint key sets**.
+
+  | producer                                                                             | keys it filled                                                                        |
+  | :----------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------ |
+  | `getDiscovery()` — `@objectstack/metadata-protocol`, upstream of REST `/discovery`   | `comments` `automation` `cron` `search` `export` `chunkedUpload` `transactionalBatch` |
+  | `getDiscoveryInfo()` — `@objectstack/runtime` dispatcher, `/.well-known/objectstack` | `search` `websockets` `files` `analytics` `ai` `notifications` `i18n`                 |
+
+  Only `search` overlapped. `DiscoverySchema.capabilities` was an open
+  `z.record`, so both shapes parsed clean and no gate could see the split — while
+  `packages/client`'s `capabilities` getter **asserted** the result was a
+  `WellKnownCapabilities`. Against a dispatcher-served host
+  `client.capabilities.transactionalBatch` was therefore statically `boolean` and
+  actually `undefined`, as were `comments`, `cron`, `export` and `chunkedUpload`.
+
+  Per the maintainer's 2026-08-06 ruling, the vocabulary is now closed and
+  mandatory.
+
+  **What a consumer sees.** Before: which capability flags exist depended on
+  which kind of host answered, and a flag you were typed to receive could simply
+  be missing. After: every discovery response carries **every** flag, always a
+  boolean. A capability the host does not deliver is `enabled: false` — never an
+  absent key — so a client can read a flag without knowing whether it reached a
+  dispatcher, the REST endpoint, or anything else. `client.capabilities` no longer
+  asserts its own return type: it enumerates the spec's key list, so the type is
+  true by construction, and it reads a key an older server omits as `false`
+  (fail-closed, matching the wire rule).
+
+  **`@objectstack/spec`.** `WellKnownCapabilitiesSchema` becomes the one
+  vocabulary and gains the six flags that were previously the dispatcher's alone
+  (`websockets`, `files`, `analytics`, `ai`, `notifications`, `i18n`) — all six
+  were already real answers on the wire, so this declares them rather than
+  inventing them. `DiscoverySchema.capabilities` changes from an optional open
+  record to a **required closed object** derived from that vocabulary, one entry
+  per key. New exports: `WELL_KNOWN_CAPABILITY_KEYS` (the key list, derived from
+  the schema so nothing can hand-list a fourth dialect) and
+  `CapabilityDescriptorSchema` / `CapabilityDescriptor` (the `enabled` +
+  optional `features` / `description` entry shape, previously inline).
+
+  Required, not optional, is the `scoping` precedent read the other way round:
+  `scoping` is optional because only one producer can honestly answer it, whereas
+  every producer can answer `capabilities` — and an optional block would leave a
+  consumer back at `undefined` for every flag.
+
+  **Producers.** Each answers all thirteen keys from its own facts, with the basis
+  recorded per key in the code. The dispatcher now measures `comments` off the
+  `sys_comment` object in the registry it already resolves for its `/data` domain,
+  and `automation` / `cron` / `export` / `chunkedUpload` off the same service
+  predicates that gate its route advertisements. Its one honest `false` is
+  `transactionalBatch`: the atomic cross-object `/batch` route is mounted by
+  `@objectstack/rest`, and this dispatcher has no batch branch at all, so claiming
+  the runtime's `transaction()` here would advertise an endpoint the host does not
+  serve. `getDiscovery()` answers the six new flags off the service registry it
+  already reads, gated on serveability so a self-declared stub does not advertise
+  a capability it cannot back.
+
+  **Gates.** The three `discovery-schema-conformance.test.ts` suites built by
+  `#5682` and extended to `routes` by `#5743` gain a fullness criterion — every
+  vocabulary key present, every `enabled` a real boolean, no key outside the
+  vocabulary — with the allowance derived from the schema rather than written out.
+
+  **Upgrading.** A producer or fixture that builds a `DiscoverySchema`-shaped
+  document must now include a complete `capabilities` block; build it from
+  `WELL_KNOWN_CAPABILITY_KEYS` rather than by hand. Consumers need no change:
+  they receive strictly more keys than before, and any flag they already read
+  keeps its meaning. The lenient wire wrapper `GetDiscoveryResponseSchema` still
+  allows the block to be absent, so a response from an older server still parses.
+
+### Patch Changes
+
+- 9fe9c1d: feat(spec): declare the action-body `ctx.session` contract (#5697)
+
+  An action body reads `ctx.session` on every dispatch, and until now **nothing
+  declared it**. `actionContext` is a bare `any` at both dispatch sites
+  (`domains/actions.ts`, `action-execution.ts`), the sandbox seam types
+  `ScriptContext.session` as `unknown`, and the one spec-side mention was an
+  inline literal on `ActionHandlerContext` carrying a `[k: string]: unknown`
+  catch-all. Declared-nowhere, produced-anyway: no schema, no gate, no generated
+  reference page, and nothing the liveness ledger could reach.
+
+  That is how the surface drifted without anyone noticing. Its `roles` key carries
+  `ExecutionContext.positions` — the ADR-0090 D3 vocabulary handed to authors under
+  the one spelling that ADR forbids — while the hook side retired its own
+  `session.roles` at #5050. One platform, one key name, two opposite answers.
+
+  **`ActionSessionSchema` (`@objectstack/spec/ui`) declares that shape as built.**
+
+  ```ts
+  { userId?: string; organizationId?: string; roles?: string[] }
+  ```
+
+  This release changes **nothing about what the runtime produces** — it is phase 1
+  of #5613's contract-first ruling, and declaring current reality is deliberately
+  not the same as endorsing it:
+
+  - `roles` is declared **deprecated** in its `.describe()` and its JSDoc. The
+    rename to `positions`, with a deprecation window and an ADR-0087 semantic
+    migration, is #5613 phase 2. There is deliberately **no `positions` key yet** —
+    minting one before the migration would ship two live spellings of one value.
+  - The schema is **not strict**, matching `HookContextSchema`: this is a runtime
+    shape the platform hands a body, never authored, and closing it would turn a
+    future engine-side enrichment into a parse failure for whoever parses a context
+    they were given.
+
+  Three facts the declaration now states, all of them previously discoverable only
+  by reading the builder:
+
+  - **Absent means the key is absent.** The builder uses conditional spreads, so
+    `'organizationId' in ctx.session` answers `false` — not "present and
+    `undefined`". The hook path's `input.id` on a bulk write is the opposite case
+    (#5668); an `in` test does not port between them.
+  - **No identity envelope yields no session at all** — `undefined`, never `{}`, so
+    a body can tell "no caller" from "an anonymous caller" (#3712). One consequence:
+    `roles` never appears on its own.
+  - **`organizationId` is the blessed name** for the caller's active org; the
+    v11-removed `session.tenantId` alias (#3280 / #3290) does not come back.
+
+  Type-only on the runtime side, no behaviour change: `buildActionSession()` now
+  declares `ActionSession | undefined` instead of `any | undefined`, and
+  `ActionHandlerContext.session` is the schema's inferred type rather than an
+  inline literal with a catch-all. A handler annotated with `ActionHandler` that
+  read an undeclared key off `ctx.session` now gets a compile error naming it —
+  that key was never produced. `ScriptContext.session` deliberately stays
+  `unknown`: it is one seam over both body kinds, and hook and action sessions are
+  different objects.
+
+  The declaration ships with the gate it needed —
+  `packages/runtime/src/action-session-shape-contract.test.ts` executes the real
+  producer and asserts a non-strict parse of the built object returns it
+  **unchanged**, so a key the builder starts producing without declaring here is
+  stripped and the pin goes red.
+
+- da5d1b4: fix(runtime): `ctx.user.name` is the acting user's display name, on every dispatch path (#5372)
+
+  An action body reading `ctx.user.name` got the raw user id back — a _declared_
+  key delivering a plausible **wrong value**, which is the failure mode
+  "declared = enforced" exists to prevent. Nothing downstream can detect it: the
+  value is a perfectly good string, so no `??` chain and no consumer-side guard
+  tells it apart from a real name. Apps that trusted the declaration wrote opaque
+  ids into user-facing surfaces (an activity timeline rendering
+  `usr_01j…` as its actor for every logged activity).
+
+  Three dispatchers built the caller's `user` object three different ways, and
+  all three landed on the id:
+
+  - **REST `/actions`** hardcoded `name: ec.userId`.
+  - **MCP `run_action`** read `ec.userName ?? ec.userDisplayName ?? ec.userId`.
+    Neither alias is declared on `ExecutionContextSchema` and nothing ever
+    assigned either, so the chain's only reachable arm was the id.
+  - **The AI routes** spelled the key `displayName` (same dead chain behind it)
+    and read the caller's address off `ec.userEmail` — the declared field is
+    `ec.email` — so `req.user.email` there was permanently `undefined`.
+
+  **What changes.** One shared producer builds the user envelope for all three
+  paths. `name` now carries `sys_user.name`, the platform's own profile
+  display-name column, resolved once per request (a memo keyed on the request's
+  ExecutionContext, so N action dispatches in one request cost one indexed read
+  — ~0.22 ms measured against real SQLite — and nothing is cached across
+  requests, so a rename takes effect on the user's next request).
+
+  Resolution is **quiet**: no `sys_user` row, no engine, a failing read or a blank
+  name falls back to the id. A missing display name never fails an action. So
+  `name === id` now means exactly one thing — _this user has no resolvable display
+  name_ — which is what makes the fix detectable from application code: any
+  workaround of the form "if `ctx.user.name` differs from `ctx.user.id`, trust
+  it; otherwise look the name up myself" **self-retires** the moment this lands,
+  with no coordinated deploy.
+
+  **One shape, and it is the spec's.** [ADR-0068 D1] declares `EvalUser` as the
+  one user-context contract, mounted under `current_user` / `user` / `ctx.user`
+  on the predicate surface — with `name` on it, meaning "display name". The
+  dispatch envelope's identity core is now built through that same
+  `createEvalUser` factory, so an action's `visible` predicate and its `body` —
+  both spelled `ctx.user` — see one object: `id`, `name`, `email`, `positions`,
+  `isPlatformAdmin`, `organizationId`. On top of that core the dispatch surfaces
+  keep publishing what they already published: `userId` and `displayName`
+  (aliases of `id` / `name`, same values), `roles` (the pre-ADR-0090 alias of
+  `positions`), and the two authority channels `permissions` (permission-set
+  names) and `systemPermissions` (capabilities), still side by side and never
+  merged. Additive for every existing reader; no key was removed.
+
+  The AI routes' second `req.user` producer (the concrete per-route mounts) is
+  built by the same function, so the two can no longer drift apart by hand. Its
+  display name comes from the session's own `user.name`, needing no extra read;
+  its former `?? user.email` middle arm is gone so that `name === id` means the
+  same thing on every producer — the address is still served under `email`.
+
+  `buildActionSandboxContext` is unchanged: it passed the user through verbatim
+  all along, and was never where the name was lost.
+
+- 9f747ee: fix(runtime): unknown `/auth` sub-paths answer a clean 404 instead of leaking an internal `TypeError` (#5085)
+
+  Measured on a real showcase boot:
+
+  ```
+  POST /api/v1/auth/login
+  → HTTP 500
+  {"success":false,"error":{"code":"INTERNAL_ERROR",
+    "message":"request.headers.get is not a function","httpStatus":500}}
+  ```
+
+  `/auth/login` is an obvious guess — it is the industry-habitual name — and any
+  integrator who tried it got a 500 naming an internal function call. The positive
+  control `POST /api/v1/auth/sign-in/email`, a real better-auth route reached
+  through the same forwarding layer on the same boot, answered 200 all along.
+
+  **The producer.** `createDispatcherPlugin` mounted one legacy explicit route,
+  `POST ${prefix}/auth/login`, and it was the only place in this repo that handed
+  better-auth a **non-Fetch** request. `IHttpServer` gives a handler the adapter's
+  internal `IHttpRequest`, whose `headers` is a plain object built from
+  `c.req.header()`; the `/auth` domain forwards `context.request` whole to
+  `IAuthService.handleRequest(request: Request)`, and better-auth's fetch-style
+  handler opens with `request.headers.get(…)`.
+
+  That route could not work for any caller: `/login` is not a better-auth endpoint
+  (it appears in neither `plugin-auth`'s route ledger nor the documented endpoint
+  list, which already stated "There is no `/auth/login` route"), and the domain
+  does not route on the sub-path at all. Its only effect over the `/auth/*`
+  wildcard the auth plugin mounts on the raw app was a 500 where the wildcard
+  yields better-auth's own clean 404. **It is deleted** — per Prime Directive #12
+  the fix belongs at the producer, not in a consumer-side conversion that would buy
+  nothing but a more expensive 404. Every unknown auth sub-path now falls to the
+  namespace owner exactly like every other one.
+
+  **The exit.** A **throw** out of `IAuthService.handleRequest` is unattributable
+  in the `/auth` domain: it never inspected the sub-path, never parsed the body,
+  and cannot tell a caller mistake from a handler bug. Its message used to reach
+  the client verbatim, because both dispatcher exits sanitise only on
+  `looksLikeInternalErrorLeak` — a SQL/driver-dump heuristic with nothing to say
+  about a `TypeError`. The message is now withheld **unconditionally**, following
+  the same discipline as `mapDataError`'s terminal `UNCLASSIFIED_FAULT` branch:
+  HTTP 500 with the catalog's `INTERNAL_ERROR` / `Internal server error`, and the
+  original error handed to the server log where an operator reads it.
+
+  Nothing changes for the honest paths. better-auth answers its own failures with a
+  `Response` rather than by throwing, so a real 401/403/404/422 is still returned
+  with its own body untouched, and `POST /auth/sign-in/email` still answers 200
+  with its `set-cookie`.
+
+- 43ca399: fix(runtime): `callData`'s ObjectQL fallback answers a missing record id with 404 `RECORD_NOT_FOUND` (#5138)
+
+  `callData` (the data bridge behind `/data`, the MCP bridge and the declarative
+  endpoint executor) is protocol-first with an ObjectQL fallback. The fallback
+  gave **three different answers to one fact** — that `id` names no row:
+
+  | verb     | before                                                      | on the wire             |
+  | -------- | ----------------------------------------------------------- | ----------------------- |
+  | `get`    | `return … : null`                                           | `200 { data: null }`    |
+  | `update` | `throw new Error('[ObjectStack] Not Found')` — no `.status` | **500**                 |
+  | `delete` | no existence check at all                                   | `200 { deleted: true }` |
+
+  The protocol path has answered `404 RECORD_NOT_FOUND` on all three verbs since
+  #4435 (re-asserted for the batch path by #5088), so the answer to the same
+  request depended on something no caller can see: whether the deployment
+  registered the `protocol` slot (`MetadataPlugin` / `@objectstack/metadata-protocol`).
+  All three fallback branches now throw the SAME envelope the protocol throws.
+
+  Two of these were actively harmful. `update` reported a caller mistake as an
+  internal fault — every dispatcher exit reads `.status` → `.statusCode` → 500, so
+  a 4xx fact entered error reporting and alerting as a 5xx. `delete` reported
+  success for a row that never existed, which is the hardest class to notice: an
+  integrator reading `200` records the cleanup as done.
+
+  The envelope is not re-spelled. `recordNotFoundError` is now exported from
+  `@objectstack/metadata-protocol` and imported by the fallback, so there is one
+  construction point and the two paths behind one `callData` cannot drift apart
+  again.
+
+  **Upgrade note.** If you run an assembly WITHOUT the metadata-protocol plugin
+  (lean hosts, and the MCP multi-env path that threads a raw driver), these three
+  calls change their answer for a missing id — from `200`/`200`/`500` to `404
+{ code: 'RECORD_NOT_FOUND', message: 'Record <id> not found in <object>' }`.
+  Deployments that DO register the protocol slot are unaffected: they already
+  answered `404` and this release does not touch that path. A client that
+  branched on `data === null` from `GET /data/:object/:id` should branch on the
+  `404` instead; a client that treated `DELETE` as idempotent should treat `404`
+  as "already gone". Declarative endpoints (`object_operation`) inherit the same
+  answer, since they reuse `/data`'s delegation.
+
+  `delete`'s existence check is a `find` probe, not a read of what `ql.delete`
+  returned: `IDataDriver.delete` declares `Promise< boolean >` and the protocol
+  can read it, but `IDataEngine.delete` declares `Promise< any >` and the engine
+  returns its driver's result through the hook chain — testing that for `false`
+  would be reading a signal the contract does not promise, and it fails in the
+  direction this fixes.
+
+- eda599e: fix(platform-objects): 超预算后台 seed 期间不再空库自证 —— 一次启动不再跑两套契约
+
+  #4769 已把 ADR-0104 的空库自证从 `kernel:ready` 挪到 `app:seeded`(本次启动自身数据的结算点),但保留 `kernel:ready` 作为「从不 seed 的内核」的兜底。剩下的窗口是这两个钩子**到达顺序可以颠倒**:`AppPlugin` 的 inline seed 超出软预算(`OS_INLINE_SEED_BUDGET_MS`,默认 8s)后转入后台,于是 `kernel:ready` 先到、兜底自证在 seed 仍在写的时候签发证书并把闸门翻到 strict——同一次 seed 运行的后半段撞上前半段从未见过的契约。showcase 冷启(`OS_INLINE_SEED_BUDGET_MS=1`)实测:自证发生在 +0.470s,seed 结算在 +3.617s,窗口 3.147s。
+
+  现在两个钩子都先问一句「本次启动自己的 seed 落定了吗」,任一处报告仍有未结算的 seed 源就不签发。`app:seeded` 同样受这道检查约束——多 config app 的 bundle 会每个 app 触发一次,第一次并不是本次启动的结算点。
+
+  新增 `seed-settlement` 契约(`@objectstack/spec/contracts`)承载这个信号,而不是让 platform-objects 去嗅 runtime 内部的 `seed-datasets` 服务:那个数组的存在只能说明「seed 源存在」,永远说明不了「已经落定」,而这两件事之间的差正是本 bug 的整个窗口。runtime 在选择分支之前先声明 seed 源,并在写入真正结束的同一刻结算它。
+
+  **multi-tenant 与 `skipSeedData` 的 ADR-0104 姿态(2026-08-06 裁定,#4795)**:这两种部署会注册 seed 数据但在启动时并不写入(前者按 org 在 `sys_organization` insert 时重放,后者是 `os migrate` 的只读规划启动,#3917),`app:seeded` 永不触发。它们的姿态是**启动时不自证,等 `os migrate … --apply` 在真实扫描的证据上落笔**——由同一个判据自然得出,不需要单独分支。这是答案而不是缺口:在启动那一刻断言一次尚未发生的 per-org 重放不含违规值,正是 #4769 的同一个错误、只是引信更长;而停在 warn-first 是可恢复的方向,随时可由 `os migrate value-shapes --apply` / `os migrate files-to-references --apply` 关闭。
+
+  `@objectstack/objectql` 侧只更新了 #4769 撤销机制的注释:「后台 seed 收尾晚于签发」不再是它要兜的场景(已在源头关闭),它对 `os dev` 热重载 seeder、运行期 marketplace 安装以及 lax 开关仍然有效。
+
+- 7bf3d1c: fix(runtime): `callData('delete', …)` 的 ObjectQL 兜底返回 spec 声明的 `{ object, id, success }`,与 protocol 路径同形 (#5581)
+
+  `callData` 是 protocol 优先 + ObjectQL 兜底,两条路径此前对「删除成功」给的是两种形状:
+
+  | 路径                   | 此前                            | 现在                            |
+  | ---------------------- | ------------------------------- | ------------------------------- |
+  | protocol(`deleteData`) | `{ object, id, success: true }` | 不变                            |
+  | ObjectQL 兜底          | `{ object, id, deleted: true }` | `{ object, id, success: true }` |
+
+  规范只有一个:`DeleteDataResponseSchema`(`packages/spec/src/api/protocol.zod.ts`)声明的是
+  `{ object, id, success }`,`deleted` 从未被任何 schema 声明;公开的 HTTP 文档
+  (`content/docs/protocol/kernel/http-protocol.mdx`)也一直写的是 `success`。所以兜底是唯一
+  的偏离方,protocol 路径与 spec、与文档都无需改动。
+
+  这是 #5138 同一族缺陷的成功侧:#5138 收敛的是「记录不存在」的答案,本次收敛的是「删除成功」
+  的答案 —— 后者是每一次正常请求都会走到的面,而非只在 id 写错时才碰到。此前按
+  `DeleteDataResponseSchema` 写的客户端,在**未注册 `protocol` 槽**的精简装配上会从一个 HTTP 200
+  里读到 `success === undefined`,即「删除到底成没成功」读不出来,而调用方无从分辨自己走的是哪条
+  路径。消费端各自兼容 `success ?? deleted` 两种拼写正是 contract-first 禁止的形状,所以修在
+  生产方,不在消费方。
+
+  ## ⚠️ 升级须知(行为变化)
+
+  **仅影响没有安装 `MetadataPlugin`(`@objectstack/metadata-protocol`,即注册 `protocol` 槽)的
+  精简装配。** 装了该插件的部署走 protocol 优先路径,本来就返回 `success`,不受影响。
+
+  在这类精简装配上,以下三个面的 `DELETE` 成功体键名由 `deleted` 改为 `success`:
+
+  - `DELETE /api/v1/data/:object/:id`
+  - MCP 的 `delete_record` 工具(`domains/mcp.ts` 的 `remove` 桥)
+  - 声明式端点(`objectParams.operation: 'delete'`,#5092)
+
+  若你的代码读的是 `response.data.deleted`,请改读 `response.data.success` —— 这也是 spec 与
+  公开文档自始至终声明的键。删除行为本身(含 #5138 落的「记录不存在则 404 `RECORD_NOT_FOUND`
+  且不发出写」)完全未变,变的只有成功体拼写这一个键。
+
+- 217b791: fix(runtime): an HTTP adapter without `setFallbackHandler` now warns that declarative endpoints are unreachable (#5400)
+
+  `setFallbackHandler` is the ONE seam by which a metadata-declared `apis:`
+  endpoint reaches a handler, and it is optional on `IHttpServer`. On an adapter
+  that omits it, every declared endpoint is permanently unservable and the caller
+  gets the transport's bare 404 — indistinguishable from a typo.
+
+  Until now the dispatcher announced that at `debug`, which the default
+  `level: 'info'` does not print at all, so operators had no signal whatsoever.
+  That level was correct only while a non-empty `apis:` was rejected wholesale at
+  publish (#4936): no deployment could be missing anything, because none could
+  declare anything. The #5040 E7 publish flip ended that premise — declarations
+  publish now and stacks ship them — so the line is raised to `warn` and carries
+  both halves AGENTS.md's "Absence must be loud" requires:
+
+  - **consequence** — every metadata-declared `apis:` endpoint is UNREACHABLE on
+    this transport and will answer a bare 404;
+  - **remedy** — compose an HTTP adapter that implements `setFallbackHandler`
+    (e.g. `@objectstack/plugin-hono-server`).
+
+  `warn` and deliberately not `error`: this is a functional degradation (a
+  capability is not mounted, and its next caller finds out), not a durability one
+  — nothing here claims to have persisted anything. The level is welded by
+  `packages/runtime/src/dispatcher-plugin.fallback-absence-warn.test.ts`, which
+  fails both on a slide back to `debug` and on escalation to `error`, and pins
+  that a conforming adapter stays silent.
+
+  Operator-visible only: no API, schema or routing change. A deployment already on
+  a conforming adapter (the default `@objectstack/plugin-hono-server`) sees
+  nothing new.
+
+- 18b8eaa: fix(runtime,tooling): `saveMetaItem` 进入持久性词表,包发布的可见性翻转不再静默丢写 (#4754)
+
+  #4632 立的「Degradation log levels」规则由 `pnpm check:durability-log-level` 机械执行,
+  但它只认 `DURABILITY_CRITICAL_CALLEES` 这张显式词表 —— 词表以外的持久性接缝它发现不了。
+  #4669 的事故正是这一类:`protocol.saveMetaItem()` 失败被吞掉,整条投影路径停摆却一个红灯
+  都没有,跨了一个发布周期才被偶然看见。本次把 `saveMetaItem` 加进词表,并把它照出来的
+  每一处逐个判过。
+
+  **真丢失的那一处已修好。** `POST /packages/:id/publish-drafts` 的 ADR-0045 可见性翻转
+  (`packages/runtime/src/domains/packages.ts`)是一次搭别人便车的元数据**写入**:草稿已经
+  发布,所以这个路由无论如何都答 200,而写失败只会在响应体里留下一个没人读的 `unhideError`。
+  症状因此是「我明明发布了,应用却没出现」,而且要很久以后才有人把它和这里联系起来 ——
+  正是 #4669 的形状。现在它按范本在 `error` 级别报告:点名是哪个包、其 app 仍然以
+  `hidden: true` 存着因而在启动器里不可见、发布却报告了成功,并给出修复动作(重跑
+  publish-drafts,幂等;或直接 `PUT /meta/app/<name>` 置 `hidden: false`),同时带上原始
+  错因。响应契约不变 —— 仍然是 200,仍然带 `unhideError`。
+
+  **闸门自身的两个精度缺陷一并修掉**(词表加一个条目就让它们暴露了,8 处命中里 4 处是误报):
+
+  - **同文件 concise-arrow 报告器看不见。** 闸门文档明说 `catch` 一侧会追同文件的 helper,
+    但遍历只访问子节点,而 `const logError = (...a) => console.error(...a)` 的函数体**就是**
+    那个调用表达式本身,于是 `rest-server.ts` 里最响的两处 `/meta` PUT 反被判成「完全静默」。
+  - **一处接缝被按嵌套层数重复指认。** 一个已被内层 `catch` 消化掉的调用,仍然算在每一层
+    外层 `catch` 头上 —— 而那些外层多半是正确的路由级错误处理器。`packages.ts` 里同一个
+    `saveMetaItem` 因此被报了三次。现在只有当内层 `catch` 每条路径都向外传播时,外层才被
+    判定为真正的守卫。
+
+  两个修复都在 `--self-test` 里双向钉住(改前必失败,改后才通过),自测用例由 CI 执行。
+
+  判定为「故障已答给调用方」的三处(`meta.ts` 的 4xx/422、`protocol.ts` 两处结构化逐项
+  失败报告)不是降级,记入 shrink-only 基线并附理由与关闭条件(#5241)。
+
+- 78adc2e: fix(runtime): disabled packages no longer come back enabled after an empty-env restart (#5047)
+
+  An operator who disables a package has that decision persisted to
+  `<OS_HOME>/package-state/<environmentId>.json`, and boot replays it by seeding
+  the registry's initial-disabled set **before** any package is registered — so
+  every registration path (boot-artifact decomposition, `sys_packages`
+  rehydration, HTTP install) installs those packages disabled.
+
+  That seed ran inside `AppPlugin.init` **after** the empty-env early return. An
+  empty environment is one whose artifact carries no app payload — which is
+  exactly the environment where every package arrives later, from
+  `PackageServicePlugin`'s Phase 2 replay of `sys_packages` or from an HTTP
+  install. So on precisely those DB-driven environments the initial-disabled set
+  stayed empty, and a package the administrator had disabled came back **enabled**
+  on every restart, with no error anywhere: the disable had persisted correctly,
+  it was simply never read.
+
+  The seed now runs before that return, alongside the default hook/action body
+  runners and the authored-translation sync, which are before it for the same
+  reason. Non-empty environments are unaffected — the seed still lands before the
+  manifest is decomposed — and the seed remains best-effort, degrading silently on
+  kernels with no engine.
+
+- 1203bb2: **声明式端点进 OpenAPI 文档;`/openapi.json` 的影子属主摘除(#5040 E6,并入 #5078)**
+
+  `GET {basePath}/openapi.json` 只有一个属主,而且实测坐实是 `packages/rest`(#5078:真实 boot 拿到 355KB 的 OpenAPI 3.1 文档,`servers[0]` 按 Host 注入、`{object}` 展开出 199 条 paths、两条 `x-template` —— 三个指纹全部是 rest-server 的行为)。因此 `apis:` 端点的文档面加入 **rest-server 既有的 enrichment 管线**(与 `{object}` 展开同根、同一次请求、同样 best-effort),而**不是**在某个 metadata service 上实现 `generateOpenApi` —— 那会造出 ADR-0076 第 1 条明令禁止的第二属主。E1 的契约成员因此已剔除。
+
+  每条声明贡献一个 path 条目:`path` 原样、`method` 小写作为 Operation 键、`operationId` = `name`,以及词表**真正带有**的两个文档字段 `summary` / `description`(缺省即缺省,不生成替身)。除此之外只写「执行器会怎么对待这条声明」的事实,逐条注明出处:`object_operation` 的 `get`/`update`/`delete` 记录 id 取 `query.id`(词表无路径模板语法)、`create` 答 201 其余 200、`script` / `proxy` 与缺 `objectParams` 的 `object_operation` 答 **501**。不编造任何 request/response schema —— 出厂文档的 `components.schemas` 是空的,凭空写 `$ref` 只会得到悬空引用。
+
+  `authRequired` 由 schema parse 物化(缺省即 `true`),为 true 的条目引用**从文档自身读出**的 security 方案(不在 rest 里硬写方案名,否则就是第二处需要保持正确的地方),为 false 的条目写显式 `security: []` —— 这是 review 时一眼能看见的那个形状。不满足 `ApiEndpointSchema` 的存量条目**响亮跳过**并点名(与端点匹配器的装载门同一姿态);同 `method+path` 撞车时按「`name` 字典序在前者胜」裁决,与匹配器**同一条规则**,否则文档会指认一个运行时并不执行的端点;撞上内建路径时内建保留,声明被略过并报错。
+
+  同时摘除 `http-dispatcher.ts` 里的 `generateOpenApi` 探测死分支:该方法在本仓与两个兄弟仓**零实现**,且 boot 实测**没有任何路由**把 `/openapi.json` 送进 `dispatch()` —— 双重死。`route-ledger.ts` 里对应的行与 `LEGACY_CHAIN_PREFIXES` 条目一并移除(原注记「falls through when metadata service lacks a generator」把「从来没有」写成了「有时没有」,正是 #5078 立单的失准点;把 prefix 留在一张自述为「if-chain 分支」的清单里,会在同一个 PR 里再造一次同样的谎)。该路由的唯一台账行在 `packages/rest/src/rest-route-ledger.ts`,一直是准的。
+
+  **现网行为零变更**:publish / validate 对非空 `apis:` 仍然硬拒(E7 前不撤),所以今天枚举出的是空集,enrichment 原样返回同一个文档对象 —— 服务出去的字节与本次改动前逐字节相同,并有测试钉住。
+
+- 2ddba89: fix(tenancy): eight sites answered "is this deployment multi-org?" with the demoted `OS_MULTI_ORG_ENABLED` (#5262)
+
+  ADR-0105 D1 made `OS_TENANCY_POSTURE` the authoritative knob and demoted
+  `OS_MULTI_ORG_ENABLED` to a back-compat _input_ of `resolveTenancyPosture()`.
+  A deployment configured the documented way — `OS_TENANCY_POSTURE=isolated` (or
+  `group`), legacy boolean unset — therefore reads `false` from
+  `resolveMultiOrgEnabled()` while running a fully mounted organization wall.
+  #5233 corrected two sites in `plugin-auth`; a census found eight more, all
+  written before that function's doc comment was corrected. Third recurrence of
+  the shape (cloud#1020, #5233).
+
+  Each site was judged separately for **which** posture answers its question —
+  what the operator REQUESTED, or what the `tenancy` service reports is actually
+  IN FORCE — rather than converted mechanically:
+
+  - `objectql` `SchemaRegistry` — the env-derived multi-tenant default. Reads the
+    REQUESTED posture (it is constructed below the kernel, with no service
+    registry to ask). The `organization_id` column was always provisioned; what
+    diverged is its INDEX, so a posture-only deployment ran the Layer 0 wall's
+    hottest predicate unindexed while SecurityPlugin compiled that same wall.
+  - `plugin-dev` — whether to load the enterprise `@objectstack/organizations`.
+    REQUESTED posture, mirroring `serve.ts`: this branch is what mounts the wall,
+    so asking whether the wall is up would be circular. A posture-only dev stack
+    previously never loaded the package at all and served traffic unwalled. Its
+    diagnostic now names the posture that was requested instead of asserting
+    `OS_MULTI_ORG_ENABLED=true` at an operator who never set it.
+  - `runtime` `AppPlugin` (inline seed + hot-reload seeder) — EFFECTIVE posture,
+    via the `tenancy` service. These ask "will the per-org replay run instead of
+    me?", and on an ADR-0093 D5 degraded boot that replay does not exist, so
+    keying on the request would defer to a replay that can never happen. Walled
+    deployments previously inline-seeded exactly the NULL-organization rows the
+    code's own comment exists to avoid.
+  - `cloud-connection` marketplace local install (install-time seed + rehydrate
+    heal) — EFFECTIVE posture, same reasoning. The install path is a write path:
+    a walled deployment wrote every sample row with no `organization_id`, landing
+    the app's data outside the wall its own reads apply.
+  - `driver-sql` `isMultiTenantMode()` — REQUESTED posture (a driver has no
+    kernel to ask, and a suppressed warning is the costlier error for a
+    diagnostic). It also no longer memoises into `_multiTenantMode`: that froze a
+    process-level fact into a per-instance verdict on whichever write landed
+    first. The gate now resolves live, which is affordable because
+    `auditMissingTenant` consults it only after the `tenantId` early-out.
+  - `cli` `os verify` — REQUESTED posture. This one produced a green verification
+    run over an unverified property: a posture-only deployment silently skipped
+    every multi-tenant proof and exited 0.
+
+  **No configuration change is needed anywhere.** Deployments setting only
+  `OS_MULTI_ORG_ENABLED=true` keep working unchanged — `resolveTenancyPosture()`
+  falls back to it — and the `OS_TENANCY_POSTURE=isolated` + `OS_MULTI_ORG_ENABLED=true`
+  belt-and-braces configuration stays valid. Deployments that set only
+  `OS_TENANCY_POSTURE` can now drop the redundant boolean. Single-org behaviour is
+  unchanged at every site; only the knob each one reads is corrected.
+
+- ef7845a: fix(runtime): 可见性翻转中途失败时,已落盘的 app 不再从响应里整批消失 (#5242)
+
+  `POST /packages/:id/publish-drafts` 的 ADR-0045 可见性翻转是一个**循环**:每个 app 一次
+  独立的 `saveMetaItem`,每次成功各自落盘。但 `unhidden` 数组声明在 `try` 之内、
+  `result.unhiddenApps` 又只在整个循环跑完之后才赋值 —— 5 个 app 里第 3 个抛异常时,前 2 个
+  **确实已经翻转并持久化**,却随栈一起被丢弃:响应里 `unhiddenApps` 压根不存在。
+
+  后果有两层,都指向同一个「机器可读面在撒谎」:
+
+  1. **响应少报了真实发生的事。** 调用方看到的是「翻转失败」,看不到「其中 2 个已经生效」。
+  2. **`metadata:reloaded` 对这 2 个 app 漏播。** 紧随其后的重绑定段读的正是 `unhiddenApps`,
+     字段缺失 → 这 2 个已经变可见的 app 不进 `changed` → boot-cached 的消费者(首当其冲是
+     automation engine)不重新同步它们,要等下一次重启。
+
+  修法按 PM 裁定取**增量累积**而非预校验:`unhidden` 与它的赋值一并提到 `try` 之外,名字只在
+  对应的 `saveMetaItem` **兑现之后**才 push,因此这个列表在任意时刻恰好等于「已经落盘的那些」。
+  赋值移到 `try/catch` 之后,成功与中途失败两条路径都会执行,并且仍在 announce 段之前 ——
+  部分失败时 `unhiddenApps` 与 `unhideError` **并存**:前者说什么翻成功了,后者说还有没翻完的。
+  `unhidden` 是每请求的局部量,不引入任何共享可变状态,符合 #5385 确立的显式传参姿态。
+
+  同时修掉那条 `error` 日志的措辞:它原先断言「其 app **全部**仍以 `hidden: true` 存着」,
+  一旦有翻转已落盘这句话就是假的。现在按两半如实点名 —— 哪些确实翻了(列出名字)、哪些仍然
+  是隐藏的,以及一如既往的后果与修复动作。
+
+  响应契约不变:仍然 200,字段还是原来那两个,只是部分失败时它们可以同时出现;重跑依旧幂等
+  (已翻转的 app `hidden !== true`,循环会跳过)。
+
+- 5aaa6fc: Deny anonymous callers on the `/actions` and `/automation` dispatch routes (#5519)
+
+  `@objectstack/rest`'s `/data` and the dispatcher's `/meta`, `/ai` and `/security`
+  have answered an unauthenticated caller 401 `UNAUTHENTICATED` since #3963 made
+  "anonymous access is always denied" a platform promise (the `api.requireAuth`
+  opt-out is a tombstone). The dispatcher's own `/actions/*` and `/automation/*`
+  routes — mounted by `dispatcher-plugin.ts` onto the host server, a different
+  registration path from the REST one — carried no anonymity check at all.
+
+  `/actions` was the expensive half: a `script` action's body executes with
+  `isSystem: true` forced on (`buildActionExecutionContext`), so an
+  unauthenticated POST bought an RLS/FLS-bypassing SYSTEM write. The only gate
+  ahead of it was ADR-0066 D4's `requiredPermissions`, which allows every action
+  that declares none — i.e. most authored actions. On `/automation`, anonymous
+  callers could trigger a flow run, list every flow, register one, and
+  unregister one.
+
+  Both domains now call the shared `shouldDenyAnonymous` decision before anything
+  dispatches, returning the same 401 envelope every other seam returns. Finer
+  authorization is unchanged and still runs for callers who clear the floor —
+  `requiredPermissions` (ADR-0066 D4), `ai.exposed`, the ADR-0104 param contract.
+
+  **What passes unchanged:** any authenticated caller (session, API key or OAuth
+  principal), and internal `isSystem` contexts. CORS preflight (`OPTIONS`) is
+  exempt as always. Internal dispatch paths never enter these HTTP handlers and
+  are untouched — the MCP `run_action` bridge, the declarative endpoint executor
+  (a `type: 'flow'` endpoint keeps its own `authRequired` gate, so an explicit
+  `authRequired: false` endpoint stays public), and engine-internal record-change
+  and schedule triggers.
+
+  **Behaviour change to expect:** an unauthenticated call that previously got 200
+  (or 403 on a `requiredPermissions` action, or 405/501) now gets 401. If a
+  deployment relied on unauthenticated action or flow invocation, the supported
+  replacement is a declared endpoint with `authRequired: false`, a public-form
+  grant, or a share-link token — never an anonymous `/actions` POST.
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [f7df82c]
+- Updated dependencies [978fed2]
+- Updated dependencies [c36abfe]
+- Updated dependencies [cfc293f]
+- Updated dependencies [d085670]
+- Updated dependencies [de70b42]
+- Updated dependencies [2f6516e]
+- Updated dependencies [01c0bae]
+- Updated dependencies [64cd010]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [7a40b7a]
+- Updated dependencies [7cf1531]
+- Updated dependencies [586d6f7]
+- Updated dependencies [2d14b35]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [c497d26]
+- Updated dependencies [e96ad55]
+- Updated dependencies [bbdbf28]
+- Updated dependencies [93929c2]
+- Updated dependencies [2e284b2]
+- Updated dependencies [3905c00]
+- Updated dependencies [4335497]
+- Updated dependencies [75bb3af]
+- Updated dependencies [43ca399]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [533a0a4]
+- Updated dependencies [1f82d1e]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [b746aa0]
+- Updated dependencies [846ed1f]
+- Updated dependencies [947d4f9]
+- Updated dependencies [d8f65fe]
+- Updated dependencies [58ffcab]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [3133cda]
+- Updated dependencies [99d7a93]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c794f78]
+- Updated dependencies [9ce0ca9]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [2b63a00]
+- Updated dependencies [06ba036]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [0f17114]
+- Updated dependencies [ecc61ab]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [96d3d4d]
+- Updated dependencies [db0d53c]
+- Updated dependencies [afa6aa5]
+- Updated dependencies [afb83d3]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [2b2175b]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [c7406b0]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [58f3220]
+- Updated dependencies [07f1822]
+- Updated dependencies [729a43a]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [08f93bc]
+- Updated dependencies [d9971d3]
+- Updated dependencies [d97f2a2]
+- Updated dependencies [d9cac60]
+- Updated dependencies [eb3e650]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [290d944]
+- Updated dependencies [02dc076]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [5d3ced9]
+- Updated dependencies [9fa6bab]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [61dc08e]
+- Updated dependencies [8dcf607]
+- Updated dependencies [b691ba9]
+- Updated dependencies [65159ae]
+- Updated dependencies [1eadac0]
+- Updated dependencies [7c2f7dd]
+- Updated dependencies [9b26699]
+- Updated dependencies [95b4f0d]
+- Updated dependencies [877545c]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [444a07c]
+- Updated dependencies [288e5a4]
+- Updated dependencies [46365ab]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [60a7a2d]
+- Updated dependencies [1c625ca]
+- Updated dependencies [b5459bc]
+- Updated dependencies [1624f4a]
+- Updated dependencies [e6db317]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [c5adfe1]
+- Updated dependencies [26e1029]
+- Updated dependencies [1cae606]
+- Updated dependencies [4addd9d]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b9cc17d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [75f82f3]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [1203bb2]
+- Updated dependencies [7d27da0]
+- Updated dependencies [de113a4]
+- Updated dependencies [db8c285]
+- Updated dependencies [0d24078]
+- Updated dependencies [089767f]
+- Updated dependencies [5b8f95b]
+- Updated dependencies [da538b1]
+- Updated dependencies [2ddba89]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [79822b5]
+- Updated dependencies [15e61fb]
+- Updated dependencies [72bd873]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [dde9202]
+- Updated dependencies [37a8f2b]
+- Updated dependencies [441d79f]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [9c5abf4]
+- Updated dependencies [dc6abfd]
+- Updated dependencies [39396bd]
+- Updated dependencies [577cd27]
+- Updated dependencies [5897552]
+- Updated dependencies [91ec1ea]
+- Updated dependencies [2d25303]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [bf1edef]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5ab0842]
+- Updated dependencies [5c94f83]
+- Updated dependencies [d275c10]
+- Updated dependencies [f98fa65]
+- Updated dependencies [73e576f]
+- Updated dependencies [2680cd3]
+- Updated dependencies [1d29e6d]
+- Updated dependencies [c5a5996]
+- Updated dependencies [5ea8e1e]
+- Updated dependencies [cba7454]
+- Updated dependencies [b40f81c]
+- Updated dependencies [db2ea82]
+- Updated dependencies [51a587d]
+- Updated dependencies [ae490ef]
+- Updated dependencies [1216dcc]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [193cd5c]
+- Updated dependencies [5aae790]
+- Updated dependencies [07f1822]
+- Updated dependencies [ef8b1ff]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [d56bcdb]
+- Updated dependencies [dca25e1]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [488b66c]
+- Updated dependencies [c89d18c]
+- Updated dependencies [acf34e3]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [90fa077]
+- Updated dependencies [e92e2c3]
+- Updated dependencies [946a131]
+- Updated dependencies [909895d]
+- Updated dependencies [38f53a0]
+- Updated dependencies [c183a12]
+- Updated dependencies [69a89ce]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+- Updated dependencies [2b52bc8]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/types@17.0.0-rc.4
+  - @objectstack/driver-sql@17.0.0-rc.4
+  - @objectstack/driver-memory@17.0.0-rc.4
+  - @objectstack/rest@17.0.0-rc.4
+  - @objectstack/core@17.0.0-rc.4
+  - @objectstack/metadata-protocol@17.0.0-rc.4
+  - @objectstack/metadata@17.0.0-rc.4
+  - @objectstack/plugin-auth@17.0.0-rc.4
+  - @objectstack/objectql@17.0.0-rc.4
+  - @objectstack/plugin-security@17.0.0-rc.4
+  - @objectstack/service-datasource@17.0.0-rc.4
+  - @objectstack/driver-sqlite-wasm@17.0.0-rc.4
+  - @objectstack/formula@17.0.0-rc.4
+  - @objectstack/metadata-core@17.0.0-rc.4
+  - @objectstack/observability@17.0.0-rc.4
+  - @objectstack/service-cluster@17.0.0-rc.4
+  - @objectstack/service-i18n@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Major Changes
diff --git a/packages/runtime/package.json b/packages/runtime/package.json
index f501755f53..6830c9c0fd 100644
--- a/packages/runtime/package.json
+++ b/packages/runtime/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/runtime",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "ObjectStack Core Runtime & Query Engine",
   "type": "module",
diff --git a/packages/sdui-parser/CHANGELOG.md b/packages/sdui-parser/CHANGELOG.md
index 6426e80c00..a7d498a31f 100644
--- a/packages/sdui-parser/CHANGELOG.md
+++ b/packages/sdui-parser/CHANGELOG.md
@@ -1,5 +1,7 @@
 # @objectstack/sdui-parser
 
+## 17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ## 17.0.0-rc.1
diff --git a/packages/sdui-parser/package.json b/packages/sdui-parser/package.json
index e034b7d145..f54b9354fd 100644
--- a/packages/sdui-parser/package.json
+++ b/packages/sdui-parser/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/sdui-parser",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "ObjectStack constrained JSX-source → SDUI SchemaNode tree compiler (parse, never execute). Isomorphic, zero React. ADR-0080.",
   "main": "dist/index.js",
diff --git a/packages/services/service-analytics/CHANGELOG.md b/packages/services/service-analytics/CHANGELOG.md
index 06cddea1f3..1768d2616f 100644
--- a/packages/services/service-analytics/CHANGELOG.md
+++ b/packages/services/service-analytics/CHANGELOG.md
@@ -1,5 +1,1544 @@
 # Changelog — @objectstack/service-analytics
 
+## 17.0.0-rc.4
+
+### Major Changes
+
+- d17df80: **BREAKING — `dashboard.widgets[].compareTo` converges on the analytics executor's contract (#5011).**
+
+  The widget declared three period-over-period arms with confident TSDoc. The analytics
+  executor implements one shape, and it was never the same one — so on the ADR-0021 dataset
+  path (the spec's own "single author-facing analytics shape") **all three arms were
+  broken**, in two different ways:
+
+  - `compareTo: 'previousPeriod'` / `'previousYear'` were **silently DROPPED** by the dataset
+    renderer. The widget rendered its base numbers and the comparison the author asked for
+    simply was not there.
+  - `compareTo: { offset: '7d' }` was forwarded into `DatasetSelection.compareTo`, whose
+    contract is `{ kind, dimension }` and has no `offset` in it — so the executor threw
+    `compareTo requires a timeDimension "undefined"` and the whole widget errored out.
+
+  All three worked on the legacy inline chart path. Same key, two fates, and the failing one
+  was the path the spec calls canonical.
+
+  `compareTo` is now a thin projection of the contract that is actually implemented:
+
+  ```ts
+  compareTo?: { kind: 'previousPeriod' | 'previousYear'; dimension?: string }
+  ```
+
+  There is no widget-side vocabulary left to drift from the executor's, so `declared =
+enforced` holds by construction rather than by review.
+
+  ## FROM → TO
+
+  | v16                                        | v17                                     | Fix                                                                                                                                   |
+  | :----------------------------------------- | :-------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------ |
+  | `compareTo: 'previousPeriod'`              | `compareTo: { kind: 'previousPeriod' }` | `os migrate meta --from 16` rewrites it                                                                                               |
+  | `compareTo: 'previousYear'`                | `compareTo: { kind: 'previousYear' }`   | `os migrate meta --from 16` rewrites it                                                                                               |
+  | `compareTo: { offset: '1y' }`              | `compareTo: { kind: 'previousYear' }`   | `os migrate meta --from 16` rewrites it — `1y` **is** `previousYear`                                                                  |
+  | `compareTo: { offset: '7d' \| '1M' \| … }` | **no faithful target**                  | State the window on the widget's own `filter` and compare with `{ kind: 'previousPeriod' }`, which shifts by that window's own length |
+
+  The last row is deliberately _not_ rewritten. `previousPeriod` shifts by the length of
+  whatever window the filter resolves to, which equals `7d` only when that window happens to
+  be seven days — a mechanical rewrite would silently change which rows the comparison
+  column counts, turning a loud failure into a wrong number. It is registered as the
+  `dashboard-widget-compareto-offset` semantic migration; the schema rejects the key with the
+  prescription in hand.
+
+  Retired at the schema, so every old spelling is a parse error carrying its own upgrade —
+  including the bare strings, which are dispatched by value so a _typo_ is still told it is a
+  typo rather than told it "was removed".
+
+  ## `dimension` is optional — resolved by the executor, not by a renderer
+
+  Omit it and `dataset-executor.ts` resolves it, by its own long-standing criterion (a
+  `timeDimensions` entry carrying a `dateRange`):
+
+  - exactly one candidate → that one is shifted;
+  - **zero** → a loud error: a comparison is only defined against a bounded window;
+  - **two or more** → a loud error **listing the candidates by name**, never a silent
+    first-wins. Picking `created_at` when the author meant `close_date` produces a comparison
+    that is _wrong_ rather than _missing_, which is the failure nobody audits.
+
+  This is a producer-side resolution rule, not consumer-side tolerance (Prime Directive
+  #12): every caller — dashboard widget, report, raw `queryDataset` — gets the same dimension
+  or the same error, and no renderer is ever in a position to guess one.
+
+  ## Notes
+
+  - `DatasetCompareTo.dimension` is now optional. Callers that always passed it are
+    unaffected; callers that relied on the old "must be present" typing get a wider type.
+  - The converged slot is **union-free**. That is not cosmetic: zod collapses a failed union
+    into one bare `Invalid input`, so curated guidance written inside a union arm never
+    reaches the author (#5014). This slot's prescriptions are top-level and do.
+  - objectui's legacy inline chart path adapts separately (objectui#3337), which also deletes
+    the `DatasetWidget` string-drop workaround this change makes unnecessary.
+
+### Minor Changes
+
+- 1792384: fix(service-analytics)!: 分析查询的 `where` —— `$not` 变 NULL-safe、`{$not:{}}` 变零行、`$or` 的 `{}` 析取项不再被丢 (#5325)
+
+  `filter-normalizer.ts` 的 `buildNode` 是这个包里**第二份**同缺陷拷贝:第一份
+  (`read-scope-sql.ts` 的 `compileNode`,RLS 读作用域)已由 #5297 修好,而这一份编译的是
+  **作者自己写的 `where`** —— dashboard widget / dataset 的筛选器。两者是各自独立的函数,
+  所以那一单合入后这三条仍然在。以 `driver-sql` 同一份 fixture 实测(4 行,行 3、4 的
+  `stage` 为 NULL,行 3 的 `amount` 为 NULL,行 4 的 `owner` 为 NULL):
+
+  | widget 的 `where`                                 | 改前取到的行 | 改后(= driver-memory / formula / #5296 后的 driver-sql) |
+  | ------------------------------------------------- | ------------ | ------------------------------------------------------- |
+  | `{ $not: { stage: 'won' } }`                      | `2`          | `2,3,4`                                                 |
+  | `{ $not: { stage: { $in: ['won'] } } }`           | `2`          | `2,3,4`                                                 |
+  | `{ $not: {} }`                                    | **全表**     | **零行**                                                |
+  | `{ $or: [{ stage: 'won' }, {}] }`                 | `1`          | 全表                                                    |
+  | `{ $not: { $or: [{stage:'won'},{owner:'u1'}] } }` | `2`          | `2,4`                                                   |
+
+  **这是可观察的行为变更,不是内部重构 —— 已有的图表数值会变:**
+
+  - **`{$not: {}}` 的 widget 此前画的是整个数据集,现在是零行。** `buildNode({})` 返回
+    `null`(= 无约束 = TRUE),`$not` 分支的 `if (inner)` 因此为假,整条 `$not` 消失,
+    WHERE 一个字都不发 —— 一条意思是「什么都不显示」的筛选器显示了全部。`NOT TRUE ≡ FALSE`,
+    现在它编译成 `1 = 0`。
+  - **`$not` 下 NULL 行的去留变了,所以图上的数字会变。** SQL 是三值逻辑而 `WHERE` 只保留
+    TRUE,裸 `NOT (stage = ?)` 把 `stage` 为 NULL 的行全部丢掉;`driver-memory`、`formula`
+    和(#5296 之后的)`driver-sql` 都把它们算进来。同一条 widget filter,在分析查询和普通
+    `find()` 上给出不同的行集,取决于哪个后端接住它。#5146 已拍板 JS 家族的答案为准,本次
+    按同一口径把守卫**下推到叶子**(`{col: {$null: false}}` / `{$or: [{col:{$null:true}}, …]}`,
+    极性逐算子决定)。**受影响的图表数值会上升**(负向筛选现在包含空值行)。
+  - **`$or` 里的 `{}` 析取项不再被丢。** TRUE 是 AND 的单位元但**吸收** OR,所以
+    `{$or: [{stage:'won'}, {}]}` 整条为 TRUE;此前它被 `.filter(n => n !== null)` 丢掉,
+    查询被静默**收紧**成剩余分支。
+  - **空集合是布尔常量,不再是「没有谓词」。** `{stage: {$in: []}}` 此前编译成空子句
+    → 无约束 → 画全表,现在是零行(`1 = 0`);`{$nin: []}` 不排除任何行。
+  - **两处新的响亮拒收(此前静默放宽):** `$not` / `$or` / `$and` 的**非对象**操作数
+    (`{$not: null}` 曾整条消失 → 等于不筛),以及**零个操作符的字段约束** `{a: {}}`
+    —— 后者按 #5240 的拍板拒收,与 driver-sql / driver-memory / formula 一致;不这么做的话,
+    「TRUE 吸收 OR」会把 `{$or: [{a: {}}, {b: 2}]}` 从 `b = 2` 放宽成全表。
+
+  实现落在 normalizer 而不是某个 strategy:守卫在这一层是**结构**(多一个 `$null` 合取项),
+  经 `filterNodeToCondition` 交给 ObjectQL 引擎后在**任何驱动上都成立**,包括本身不 NULL-safe
+  的那些;只加在 raw-SQL 那条路径,等于说「分析查询的 `$not` 是什么意思取决于哪个驱动接住它」。
+  代价是引擎路径会**双重加守卫**,已实测幂等(`NOT (c IS NOT NULL AND (c IS NOT NULL AND c = v))`
+  与单层等价),只是 SQL 多一层冗余谓词。
+
+  `NormalizedFilterNode` 因此新增布尔常量 kind —— 该联合此前只有 `leaf | and | or | not`,
+  没有 FALSE 的表示法,这正是 `{$not:{}}` 只能编译成「什么都不发」的根本原因。三个编译器
+  (`native-sql-strategy.compileFilterNode`、`objectql-strategy.filterNodeToCondition`、
+  回显给浏览器的 `renderFilterNodeSql`)各自实现它;引擎路径用的是 `{$not: {}}`,即
+  driver-sql / formula / driver-memory 参考匹配器早已钉住的零行写法(#5134),没有另造第二种。
+
+  `$and: []` / `$or: []` 的空组合子**不在本次范围**,仍然 fail-closed 抛错(独立裁定见 #5322),
+  并已加用例钉在抛错这一侧。
+
+- 1f0e7cb: fix(service-analytics): reject a dataset's cross-datasource JOIN when it is compiled, not when it is queried (#5115)
+
+  #5033 routed a dataset's raw SQL to its base object's own datasource, which
+  turned a JOIN whose target lives in another database into a **loud query-time
+  failure** — correct, but late: the dataset can still be saved, published and
+  put on a dashboard, and the failure lands in front of whoever opens that
+  dashboard, usually in another environment on another day. It is a pure metadata
+  error, decidable the moment the dataset is compiled: the whole dataset is
+  lowered into ONE statement on the base object's datasource, so a join target
+  bound elsewhere is simply not there.
+
+  `compileDataset` now decides it. `AnalyticsService.registerDataset` — the single
+  door every dataset passes through, whether pre-registered at boot, saved, or
+  previewed as a Studio draft — hands the compiler the datasource and federation
+  probes that already existed on `AnalyticsServiceConfig`, and a proven conflict
+  is rejected before any SQL is built. The message names both objects, both
+  datasources, the offending `include` path, and the two ways out (bind both
+  objects to the same datasource, or drop the relationship), in the same wording
+  family as the #5033 query-time diagnostic so the two never read as two bugs.
+
+  **Who is affected.** This is a tightening: a dataset that used to compile and
+  then fail (or, before #5033, silently read the wrong database) now fails at
+  registration. It fires only where the metadata _proves_ the conflict — the base
+  object and a join target each declare an explicit `object.datasource` and the
+  two names differ. A dataset registered at boot is skipped with a WARN naming the
+  conflict, as before; the rest of the host's datasets still register.
+
+  **What is deliberately not rejected** ("cannot answer, do not block", the same
+  tiering as `isRegisteredObject` / `getObjectFieldNames`):
+
+  - a host that wires no datasource probe at all (no data engine) — compiles
+    exactly as it did before;
+  - either side leaving `datasource` at its default. `'default'` is the schema's
+    default _value_, not a routing decision: `ObjectQL.getDriver` short-circuits
+    only on an explicit non-`'default'` name, then falls through to
+    `datasourceMapping` rules, the ADR-0057 §3.6 lifecycle split
+    (audit/telemetry/event) and the owning package's `defaultDatasource` — none of
+    which are visible to the compiler. Treating `'default'` as "the primary DB"
+    would reject datasets whose objects a mapping rule in fact lands on the _same_
+    database;
+  - a federated (external) participant on either side. `NativeSQLStrategy` already
+    declines such a cube (ADR-0062 D6), so the query is served by the ObjectQL
+    FK-expand path, which crosses datasources by construction.
+
+  Everything not proven here keeps failing loudly at query time via #5033.
+  Making cross-datasource dashboards actually _work_ (declining in
+  `NativeSQLStrategy` and serving the join with two reads) is separate and not
+  part of this change.
+
+### Patch Changes
+
+- c637387: fix(service-analytics): only a canonical numeric spelling is recovered as a number, so `'007'` / `'1.50'` stay strings (#5528)
+
+  An analytics `where` round-trips every comparand through the internal
+  `values: string[]` form — `stringifyForCube` on the way out, and
+  `coerceFilterValueForSql` / `coerceFilterValueForObjectQL` on the way back. The
+  decoder decided "this is a number" from the string's **shape** alone
+  (`/^-?\d+(\.\d+)?$/`), which cannot distinguish a number that was stringified on
+  the way out from a string the author actually wrote.
+
+  Measured before the fix, on cube `orders` / TEXT column `code`:
+
+  | author's `where`        | leaf `values` | SQL bind | engine comparand |
+  | ----------------------- | ------------- | -------- | ---------------- |
+  | `{code: {$eq: '007'}}`  | `["007"]`     | `7`      | `7`              |
+  | `{code: {$eq: '0912'}}` | `["0912"]`    | `912`    | `912`            |
+  | `{code: {$eq: '1.50'}}` | `["1.50"]`    | `1.5`    | `1.5`            |
+
+  Both consumers were affected: the raw-SQL bind in `NativeSQLStrategy` and the
+  comparand handed to the ObjectQL aggregate engine.
+
+  The failure was **silent and mis-targeted, not empty**. Against a text column
+  SQLite applies the column's affinity to the integer bind, so a widget filtered on
+  order number `'007'` returned the row storing `'7'` — a different row, with no
+  error to read; on Postgres the same query is a `text = integer` type error, and on
+  the engine path the strict comparison simply matched nothing (measured: 0 rows).
+  Zero-padded and trailing-zero strings are ordinary business shapes — order
+  numbers, work orders, SKUs, dialling codes, postcodes, `'1.50'` prices.
+
+  Recovery is now limited to a number's **own canonical spelling**
+  (`String(Number(s)) === s`):
+
+  - a comparand that really was a number is `String(n)` by construction, so it
+    still round-trips — `7` → `'7'` → `7`, `1.5` → `'1.5'` → `1.5`, `-3` → `-3`;
+  - a string `Number()` would rewrite — `'007'`, `'0912'`, `'1.50'`, `'1.0'`,
+    `'-0'`, or more digits than a double holds — cannot have come from a number, so
+    it stays the string the author wrote.
+
+  The narrowing can only ever **remove** recoveries: the shape regex still runs
+  first, so `'1e3'`, `'1e+21'`, `'+7'`, `' 7'`, `'0x10'`, `'Infinity'` and `'NaN'`
+  were strings before this change and are strings after it. This also aligns with
+  ADR-0053 D-A2, which demoted this textual type re-derivation to a last resort
+  behind the driver-backed `coerceTemporalFilterValue` hook.
+
+  **Stopgap, and named as one.** `values: string[]` still has no escape, so the
+  author strings `'null'` / `'true'` / `'false'` still collide with the tokens the
+  encoder writes for the real `null` and booleans. Making the round trip lossless —
+  tagged values, or an `unknown[]` internal representation — is #5526; the
+  collision is pinned as unchanged in
+  `src/__tests__/filter-value-canonical-number.test.ts` so it is not mistaken for
+  fixed.
+
+- c113690: fix(service-analytics): `contains` 以规范算子 `$contains` 送进引擎,比较值不再落进正则位置(#5557)
+
+  `ObjectQLStrategy.convertFilter` 在同一个 `switch` 里处理 LIKE 家族的四个算子。
+  其中三个(`notContains` / `startsWith` / `endsWith`)自 #4128 起就是规范 spec 算子,
+  只有 `contains` 是 `{ $regex: values[0] }` —— 比较值**原样**放进一个正则位置,不转义。
+
+  实测(修复前 → 修复后,引擎收到的 filter):
+
+  | `where`                          | 修复前                           | 修复后                        |
+  | -------------------------------- | -------------------------------- | ----------------------------- |
+  | `{stage: {$contains: 'a.b'}}`    | `{stage: {$regex: 'a.b'}}`       | `{stage: {$contains: 'a.b'}}` |
+  | `{stage: {$notContains: 'a.b'}}` | `{stage: {$notContains: 'a.b'}}` | 不变                          |
+  | `{stage: {$startsWith: 'a.b'}}`  | `{stage: {$startsWith: 'a.b'}}`  | 不变                          |
+  | `{stage: {$endsWith: 'a.b'}}`    | `{stage: {$endsWith: 'a.b'}}`    | 不变                          |
+
+  三条后果,都是作者没有要求过的行为,且都不依赖 #4706 对 `$regex` 语义的裁决:
+
+  1. **`$regex` 不在契约里。** `filter.zod.ts` 的 `FILTER_OPERATORS` 声明 15 个算子,
+     没有 `$regex` —— 这是**生产方**在发送 schema 未声明的算子。按 Prime Directive #12
+     修生产方(一个 `case` 标签),而不是给消费方加宽容。
+  2. **同一棵过滤树在同包两个消费方之间不通。** `read-scope-sql.ts` 的
+     `compileScopedFilterToSql` 也是一个 `FilterCondition` 消费方,`compileOperator`
+     的 `default` 是 fail-closed,于是它对本策略产出的 filter 直接抛
+     `unsupported operator "$regex" … (fail-closed)`。
+  3. **行结果取决于哪个驱动来答。** 把 `$regex` 当真正则求值的后端(driver-memory 的
+     `memory-matcher.ts` 就是,而且是有意为之 —— 服务 plugin-auth 的 ObjectQL adapter)
+     把 `a.b` 读成「a、任意一个字符、b」,于是 `axb` 也被匹配上;而 `50% (+)` 作为正则
+     根本编译不过(`Nothing to repeat`),`catch` 之后 `return false` —— 一个**有匹配行**
+     的筛选器静默返回零行,作者那边只看到「无数据」。同一个 `$contains` widget 在
+     `driver-sql` 上则被编译成子串 LIKE:同一张 dashboard,不同驱动,不同行集。
+
+  `filter-normalizer.ts` 的 `MONGO_TO_CUBE_OP` 只把 `$contains` 映到 `contains`,
+  别无来源,所以这里回送 `$contains` 就是作者自己那个 key 的往返。
+
+  **测试**(`objectql-contains-canonical-operator.test.ts`,新增):引擎 filter 的算子键
+  逐个对 `filter.zod.ts` 的 `ALL_OPERATORS` 校验(取自 spec 而非手抄一份);行结果跑在一个
+  复刻 `memory-matcher.ts` 各 arm 的求值面上 —— `a.b` 只命中字面行、`50% (+)` 命中它该
+  命中的那一行且**恰好**只有那一行(修复前分别是多一行和空集);同一个 filter 再送进
+  `compileScopedFilterToSql` 确认它现在编译得过。只断言 filter/SQL 字符串会漏掉「不转义」
+  这一半,所以两半都断言。
+
+  顺带删掉 #5558(PR for #5333)在 `objectql-echo-operator-coverage.test.ts` 的替身引擎里
+  留下的那处 `$regex` → `$contains` 翻译:它存在的理由就是本单,现在没有了。那也是本修复
+  最直接的反向证据 —— 把 `case 'contains'` 退回 `$regex`,该文件的 `$contains` 行会以
+  上面第 2 条的 fail-closed 报错红掉。
+
+- 705efeb: fix(analytics): a dataset refusal that declares an ADR-0112 envelope is never degraded to an empty result (#5717)
+
+  `queryDataset` wraps execution in a catch that exists for one deliberate reason
+  (#5033): a widget whose backing object is not mounted in this kernel renders
+  "no data" instead of failing with a 500. The criterion for "not mounted" was
+  `isMissingSourceError` — a substring match over the error MESSAGE. So the
+  leniency was available to any error that happened to phrase itself like a
+  driver, and #5352 / #5367's finding on the REST face — "the wire shape of an
+  error family must not be a property of its wording" — applied here one level
+  worse: the outcome was not a wrong status code but a **silent empty result**.
+  No exception, no 4xx, no 5xx; one `warn` line and a confident empty chart, which
+  is the "populated table, Total Spend: 0" symptom #5033 was filed about.
+
+  One refusal already matched. `dataset-compiler.ts` refuses an `include` naming a
+  relationship the object graph does not have with
+
+  > `[dataset-compiler] dataset "X" includes relationship "R" which does not exist on object "O".`
+
+  which carries both `relation` (inside "relationship") and `does not exist` — and
+  that conjunction was the postgres limb. It has never gone off for one reason:
+  `queryDataset` compiles **before** the try, so that throw has never been inside
+  the catch's reach. A mine, wired and unarmed.
+
+  **Two independent defences, so the disarming does not depend on either one.**
+
+  - **The criterion (main change).** An error carrying an ADR-0112 envelope —
+    numeric `status` + non-empty `code`, the same structural fact
+    `rest-server.ts`'s `/analytics/dataset/query` catch reads — is re-thrown
+    untouched, ahead of any message inspection. Its producer already answered the
+    classification question. The status RANGE is deliberately not part of the
+    test: a `DATASET_INVALID` / 400 rendered as an empty grid is the loud case,
+    but a declared 5xx (`READ_SCOPE_COMPILE_FAILED` — an RLS lowering that failed
+    closed) is if anything worse to swallow, since nobody is told at all.
+  - **The sniffer.** Its postgres limb is now anchored to postgres's actual
+    wording (`relation "x" does not exist`) instead of "any sentence containing
+    both words" — the same pattern the sibling `missingSourceRelation` already
+    used, so "is something missing" and "what is missing" can no longer disagree.
+
+  **Observable behaviour change — read this if you alert on empty widgets.** The
+  guarantee is new, not the status of any shipped message: measured over the 13
+  real wordings this repo carries (three driver families including sql-prefixed
+  and schema-qualified forms, the framework's not-registered signals, and this
+  package's own refusals), exactly one verdict moves — the compiler refusal above,
+  which reaches callers as `400 DATASET_INVALID` either way because its throw site
+  sits outside the try. What changes is that a caller-shaped refusal raised
+  **during execution** can no longer become `{rows: [], fields: [], totals: []}`
+  by phrasing alone: it now propagates and the route answers its declared code
+  (4xx as itself, declared 5xx through `ANALYTICS_QUERY_FAILED`). A dashboard that
+  silently rendered an empty chart for such a refusal will now surface the error.
+
+  **#5033's leniency is untouched, and that is asserted rather than claimed.** A
+  bare driver error is still classified by its words and still degrades: `no such
+table` (sqlite/libsql), postgres's real `relation "x" does not exist`, mysql's
+  `doesn't exist`, the framework's not-registered signals — and a bare error
+  naming a JOINED table still fails loudly as a cross-datasource dataset. Those
+  cases are green in all four states of the reverse verification
+  (`dataset-degradation-envelope.test.ts`), including with both defences reverted.
+
+  The compile point deliberately stays outside the try. Moving it in would newly
+  expose the compiler's own bare invariants and the host-supplied relationship
+  resolver to this degradation path — widening leniency in the opposite direction
+  from the fix.
+
+- 978fed2: fix(analytics,rest): five dataset refusals declare `DATASET_INVALID` / 400 themselves, and the route's message-sniffing list shrinks to one entry (#5367)
+
+  `POST /analytics/dataset/query` answered `400 DATASET_INVALID` for six error
+  families because the route recognised their **prose**, not because the errors
+  said anything about themselves. #5352 gave the catch an ADR-0112 envelope branch
+  (`error.code` + a 4xx `error.status`, read first) and had to leave a hardcoded
+  list of message substrings behind it, since all six producers were still bare
+  `throw new Error(…)`:
+
+  ```
+  /not declared in the dataset|not backed by a declared relationship|
+   not supported by the v1 dataset runtime|read-scope-sql|
+   not a selected dimension or measure|is not a subset of the selected dimensions/
+  ```
+
+  That made the HTTP status of six families a property of their wording.
+  Rephrasing `dataset-compiler`'s "is not declared in the dataset's `include`" —
+  no logic change — moved that refusal from 400 to 500, i.e. re-opened #5352 for a
+  different family, and no test and no gate would have gone red. Prime Directive
+  #12 permits an accommodation like that only while it is declared, loud, tested
+  **and removable on a schedule**; #5366 delivered the first three and nothing
+  carried the fourth.
+
+  **Five producers now declare their own verdict.** A new
+  `dataset-refusal.ts` in `@objectstack/service-analytics` exports
+  `datasetInvalidError` — the same shape as that package's existing
+  `invalidFilterError` (`INVALID_FILTER` / 400) and `assertDimensionFields`
+  (`INVALID_FIELD` / 400) — and five sites throw through it:
+
+  - `dataset-compiler.ts` — a measure whose aggregate the v1 runtime cannot lower;
+    a dimension/measure traversing a relationship path the dataset never declared
+    in `include`;
+  - `dataset-executor.ts` — an `order` key that is not a selected dimension or
+    measure; a `totals` grouping that is not a subset of the selected dimensions;
+  - `native-sql-strategy.ts` — a join outside the dataset's declared allowlist.
+
+  Their five entries are gone from the route's list, which is now a single
+  `read-scope-sql` test.
+
+  **`read-scope-sql` deliberately stays.** Its ten fail-closed refusals are RLS
+  read-scope lowering failures whose inputs are an admin-authored policy and a
+  compiler-generated join alias — not caller input — so `DATASET_INVALID` ("your
+  request is invalid") may well be the wrong verdict and choosing the right one is
+  a separate judgement, still tracked by #5367. Deleting the entry before that
+  judgement lands would regress those ten from `400 DATASET_INVALID` to 500.
+
+  **No outward behaviour change for the five.** They answered
+  `400 DATASET_INVALID` before and answer `400 DATASET_INVALID` now, with the same
+  message; what changed is the mechanism, from message-matching to the producer's
+  own declaration. The one visible difference is for a bare `Error` that merely
+  _resembles_ one of those messages: it is no longer promoted to a 400. That is the
+  point — a phrase is no longer a classification.
+
+  `DATASET_INVALID` is registered in `ERROR_CODE_LEDGER` under
+  `@objectstack/service-analytics` as well as `@objectstack/rest` (provenance, per
+  ADR-0112 D3; the code itself is unchanged and the union does not grow), and the
+  constructor types it as `RegisteredErrorCode` so an unregistered code is a
+  compile error rather than a body some route rejects at runtime.
+
+  Coverage: `dataset-refusal-envelope.test.ts` (service-analytics) pins each of the
+  five refusals against its real producer — the refusal SET first, green before and
+  after, then the envelope; `analytics-dataset-refusal-envelope.test.ts` (rest)
+  drives all five end-to-end through a real `AnalyticsService` with positive
+  controls on both the aggregate and raw-SQL paths; and
+  `analytics-filter-refusal-envelope.test.ts` pins the deletion in both directions
+  — the five messages answer 400 when enveloped and 500 when bare, so re-adding a
+  regex entry turns it red.
+
+- c36abfe: fix(service-analytics,rest): an analytics dimension over a missing field answers 400 INVALID_FIELD, not a driver 500 (#5520)
+
+  #4437 gave a **measure** over a non-existent field a `400 INVALID_FIELD` naming
+  the field, because a driver error class must never be the caller's `error.code`
+  for a caller-shaped mistake (ADR-0112). It covered the measure half only, so the
+  identical typo one request key over still reached the driver as a `GROUP BY`
+  column:
+
+  ```
+  POST /analytics/query {"cube":"account_metrics","measures":["account_count"],"dimensions":["bogus_dim"]}
+  → 500 {"code":"SQLITE_ERROR","message":"Internal server error"}
+
+  # the control group on the same route, already fixed by #4437
+  POST /analytics/query {"cube":"account_metrics","measures":["bogus_measure"]}
+  → 400 {"code":"INVALID_FIELD","message":"Measure 'bogus_measure' … Valid measures: …"}
+  ```
+
+  **The gate.** `ensureCube` now runs `assertDimensionFields` alongside
+  `assertMeasureFields` on every path, so a dimension whose source column the
+  backing object does not have is refused **before** any SQL is built, with the
+  same envelope the measure gate uses: `INVALID_FIELD` / 400 plus
+  `field` / `object` / `param`, a message naming the field, the valid dimensions,
+  and the object's known field list. `query`, `generateSql` and `queryDataset` are
+  all covered, and a rejected query leaves nothing behind in the cube registry.
+  `timeDimensions` are covered too — they resolve through the same
+  `cube.dimensions` bag and produced the same 500 — with `param` reporting which
+  request key carried the bad name.
+
+  **What deliberately did not change:** grouping by a REAL field the cube never
+  declared as a dimension (`dimensions: ["phone"]`) still works. The gate asks
+  "does the _object_ have this field", never "did the cube declare this
+  dimension". A cube whose `sql` is an expression, a dotted relation dimension,
+  and a host that wires no field-name probe are all stood down on, exactly as the
+  measure gate stands down.
+
+  **The SQL echo, same request.** `POST /analytics/dataset/query` composed its own
+  5xx body and echoed the error message verbatim. Knex prefixes the offending
+  statement to its message, so the caller received the generated SQL — physical
+  table and column names included:
+
+  ```
+  500 {"code":"ANALYTICS_QUERY_FAILED",
+       "error":"SELECT bogus_dim AS \"bogus_dim\", COUNT(*) AS \"account_count\"
+                 FROM \"crm_account\" GROUP BY bogus_dim - no such column: bogus_dim"}
+  ```
+
+  The sibling face never leaked it: `/analytics/query` exits through the
+  dispatcher, which has applied the shared `looksLikeInternalErrorLeak` predicate
+  to every >= 500 message since #3867. That same predicate now guards this route's
+  500 body. Classification is untouched — the status stays 500, the code stays
+  `ANALYTICS_QUERY_FAILED`, the ADR-0112 envelope branch and the transitional
+  message list are unchanged — and the full text still reaches server logs. A 500
+  whose message does not look like driver output keeps its prose.
+
+- 9ecdca9: fix(service-analytics): `/analytics/sql` 回显补上 `$startsWith` / `$endsWith` 谓词(#5333)
+
+  `ObjectQLStrategy.generateSql` 是同一棵过滤树的**第三个**编译器 —— 输出给浏览器的
+  展示 SQL。它的 `buildFilterClauseSql` 显式处理 `set`/`notSet`/`in`/`notIn`/
+  `contains`/`notContains`,其余落到只有六个条目的 `SCALAR_SQL_OPS` 查表;
+  `startsWith` / `endsWith` 两处都不在,于是走到 `return null`,而**这棵树的每个编译器
+  都把 `null` 读成「本节点没有约束」**。结果:
+
+  | `where`                       | 实际执行(`NativeSQLStrategy`)    | 修复前的回显                    | 修复后的回显                     |
+  | ----------------------------- | -------------------------------- | ------------------------------- | -------------------------------- |
+  | `{stage: {$startsWith: 'w'}}` | `WHERE stage LIKE $1` / `['w%']` | **没有 WHERE**,`params` 为空    | `WHERE stage LIKE $1` / `['w%']` |
+  | `{stage: {$endsWith: 'n'}}`   | `WHERE stage LIKE $1` / `['%n']` | **没有 WHERE**,`params` 为空    | `WHERE stage LIKE $1` / `['%n']` |
+  | `{stage: {$contains: 'w'}}`   | `WHERE stage LIKE $1`            | `WHERE stage LIKE $1`(本来就对) | 不变                             |
+
+  回显比实际执行的查询**更宽**。这个字符串存在的唯一理由就是复现执行 —— 文件自己在渲染
+  块顶上写着 “a rendering that contradicts execution is worse than no rendering” ——
+  所以一个带着「为什么这张图少了几行」来看回显的作者,拿到的是一条**没有该筛选条件**的
+  语句:跑一遍返回更多行,于是结论是「筛选器没生效」,而实际执行是生效的。与
+  #3601 / #3602 / #3650 同一类「回显与执行不一致」,只是这次是从**算子表**这一侧到达的。
+
+  不涉及越权或错行:该字符串从不执行(`execute()` 的 echo 会丢弃 `params`),损害限于
+  可调试性。
+
+  **两处修改:**
+
+  1. **LIKE 家族收进一张表。** 新增 `LIKE_SQL_OPS`,四个算子(`contains` /
+     `notContains` / `startsWith` / `endsWith`)的 SQL 拼写与 pattern 并排放在一起,
+     与 `NativeSQLStrategy.buildFilterClause` 的 `opMap` / `likePattern` 逐条对应 ——
+     回显描述的正是那个编译器产出的语句,两张表并列摆着,漂移才看得见。
+     `contains` / `notContains` 的产物一字未变。
+
+  2. **「渲染不了就静默丢」的出口改为 THROW。** `return null` 在这里与「无约束」同形,
+     所以下一个新增算子会以同样的方式再丢一次。之所以**可以**抛错:上游算子词汇表是
+     **封闭**的 —— `filter-normalizer.ts` 的 `fieldLeaves` 是叶节点的唯一生产者,它对
+     `MONGO_TO_CUBE_OP` 之外的算子在建叶之前就以 `INVALID_FILTER` / 400 拒绝。因此任何
+     调用方写出的过滤器都到不了这个出口;真到了,只能意味着 normalizer 的表新增了这里
+     没有分支的算子,那是我们自己两张表漂移,而对此**唯一不能给的答案就是悄悄放宽作者的
+     查询**。与 `convertFilter` 的 `default:` 分支在 #4128 做出的是同一个选择;刻意**不**用
+     `invalidFilterError` 的 400 信封 —— 这不是调用方形状的错误。
+
+  **该 throw 出口今天从公共入口不可达,这一点是测过的、也是刻意报告的**:把它改回
+  `return null`(保留第 1 项修改)只会让它自己那一条断言变红,枚举断言和回显对照表
+  全部保持绿色。它是一个漂移探针,不是行为修复 —— 行为修复是第 1 项。
+
+  新增 `objectql-echo-operator-coverage.test.ts`:issue 那张对照表按**行结果**钉住
+  (回显语句在同一份 fixture 上真的被执行,行 id 与查询实际返回的行 id 比对 —— 丢掉的
+  谓词藏不住,它返回的正是筛选器排除掉的行),再按 `filter.zod.ts` 的
+  `FILTER_OPERATORS` 枚举全部 15 个可编写算子,逐个断言回显渲染出谓词、且
+  placeholder 与 `params` 对齐。只断言 SQL 字符串会放过下一个未映射的算子 —— #4128 里
+  `$between` 就藏在 `$startsWith` 后面。
+
+- cfc293f: fix(service-analytics): 空 `$and` / `$or` 按布尔单位元归约,两个编译器与五后端对齐 (#5322)
+
+  同一个仓库对空组合子曾有两个对立答案:五个 `FILTER_LOGIC_CASES` 后端
+  (`driver-sql` #5134/PR #5243、`driver-memory`、`formula`、`driver-sqlite-wasm`、
+  `driver-mongodb` #5239)把 `{ $and: [] }` / `{ $or: [] }` 归约成布尔单位元,而
+  service-analytics 的两个编译器 —— `read-scope-sql.ts` 的 `compileNode` 与
+  `filter-normalizer.ts` 的 `buildNode` —— 成文地 fail-closed 抛错("An empty
+  combinator has no defensible reading…"),并有 pin 测试钉住。2026-08-04 维护者拍板
+  (#5322)取单位元,本次把两处对齐:
+
+  - `{ $and: [] }` = TRUE(全部行,AND 单位元);`{ $or: [] }` = FALSE(零行,OR
+    单位元)。嵌套可归约:空组合子作 `$or` 分支时按 TRUE 吸收/FALSE 退出析取,作
+    `$not` 操作数时取反(`{$not: {$and: []}}` = 零行、`{$not: {$or: []}}` = 全部
+    行)。`{}` = TRUE 与 `{ $not: {} }` = 零行两格已由 #5297(read-scope)/#5325
+    (normalizer)先行落地,本次连同这四格由同一张一致性表钉住。
+  - **迁移含义**:过去发出空组合子的调用方收到的是抛错(REST 面上是一次失败的请
+    求);现在按上表求值。`{ $or: [] }` 在 RLS/图表场景是 fail-closed 的 —— 析取列
+    表循环出零项时隐藏全部行,而不是放行全表。写作期对字面量空组合子的响亮拒收另立
+    #5330(publish/lint),不在运行期。
+  - **没有放宽的部分**:非数组的 `$and`/`$or`、非对象的分支、非对象的 `$not` 操作数
+    仍然抛错(#5325 的形状拒收原样保留)。归约让「无约束」成为有意义的裁决,静默把
+    畸形分支读成 TRUE 会让垃圾析取项吸收 `$or` 而放宽查询,所以畸形形状保持响亮。
+  - 归约与 #5146/#5325 的 NULL-safe `$not` 重写的组合语义是「先归约、后 NULL-safe」
+    —— 常量归约出的单位元不受重写影响,幸存的叶子照常加守卫,有测试钉住。
+  - `packages/spec`:`FILTER_LOGIC_CASES` 补四条布尔单位元行(空 `$and`、空 `$or`、
+    `{}` 析取项吸收、`{$not: {}}`),两个 analytics conformance suite 与五后端从此
+    被同一张表钉住这四格。
+
+- de70b42: analytics: `$ne` / `$nin` / `$notContains` in a dashboard `where` keep the rows that have no value
+
+  Second batch of the #5298 ruling, after PR #5962 landed it on `driver-sql`,
+  `read-scope-sql` and `formula`. An analytics filter meaning "not this" now
+  returns the rows whose column is empty, the same answer every other backend
+  gives — a `stage != 'won'` widget shows the deals with no stage set.
+
+  The Cube face was the last surface still splitting on it, and it split three
+  ways for one filter. Measured on the package's own fixture before the change,
+  for `{stage: {$ne: 'won'}}` with rows 3-4 carrying a NULL `stage`:
+
+  | compiler                            | was     | now     |
+  | ----------------------------------- | ------- | ------- |
+  | `NativeSQLStrategy` raw SQL         | `2`     | `2,3,4` |
+  | `ObjectQLStrategy` display-SQL echo | `2`     | `2,3,4` |
+  | `ObjectQLStrategy` engine condition | `2,3,4` | `2,3,4` |
+
+  The engine column was already right — because `driver-sql` guards for itself
+  since #5962, not because the analytics layer did — so which rows a widget drew
+  depended on which compiler downstream caught the leaf, and the `/analytics/sql`
+  echo described a narrower query than the one that ran.
+
+  `filter-normalizer` now emits the guard as tree STRUCTURE (an `or` of the null
+  predicate with the comparison) rather than as a SQL trick in one strategy, so
+  all three compilers of that tree produce one predicate and none of them needs
+  to know the rule. Which operators are guarded is decided by the polarity table
+  the `$not` rewrite already consults, not by a second list of operator names:
+  positive comparisons (`$eq`, `$in`, `$contains`, the ordering family) compile
+  byte-identically to before, `$ne: null` stays `IS NOT NULL`, an empty `$nin`
+  stays the TRUE constant, and `{$not: {stage: {$ne: 'won'}}}` still means
+  "stage is won" rather than widening.
+
+  `FILTER_LOGIC_CASES` is unchanged: the `$ne` and `$not` null rows enrol in
+  #5903's PR, which clears the last backend (`driver-turso` remote). The spec
+  table's measured blocker matrix drops the Cube row it no longer describes.
+
+- 2f6516e: fix(analytics,rest): an analytics filter refusal reaches the caller as `400 INVALID_FILTER`, not `500 ANALYTICS_QUERY_FAILED` (#5352)
+
+  Misspell an operator in a dashboard widget's filter and analytics refuses it —
+  correctly, and loudly, which is the posture #3948 / #5240 / #5325 / #5334 each
+  argued for one refusal at a time: dropping a predicate the compiler cannot
+  express does not narrow the query, it **widens** it to rows the author excluded,
+  and a chart drawn over the whole dataset looks like a working chart.
+
+  The refusal never reached the author. It landed as `500 ANALYTICS_QUERY_FAILED`
+  — read as "the platform is broken" rather than "your filter has a typo", and
+  counted by ops alerting as a 5xx. The identical mistake on `find()` has answered
+  `400 INVALID_FILTER` since #3948, so one authoring error had two wire shapes,
+  chosen by which face happened to catch it.
+
+  **One defect, two halves — either alone leaves it unfixed.**
+
+  - **Producer** (`filter-normalizer.ts`): seven of its nine refusals were bare
+    `throw new Error(…)` carrying no `code`/`status`. All nine now go through the
+    `invalidFilterError` helper #5334 introduced (`INVALID_FILTER` / 400), which
+    becomes the module's only way to refuse.
+  - **Consumer** (`rest-server.ts`, `POST /analytics/dataset/query`): the catch
+    discarded `error.code` / `error.status` and re-derived the classification from
+    a hardcoded list of message substrings — so a producer that took ADR-0112
+    seriously was punished for it. It now reads the envelope **first**; the
+    substring list is demoted to a fallback for the families that still carry no
+    envelope.
+
+  **Observable behaviour change — read this if you alert or retry on status.**
+  The same request that returned `500 ANALYTICS_QUERY_FAILED` now returns
+  `400 INVALID_FILTER` (and, for two neighbouring conditions whose producers
+  already declared an envelope this route was discarding, `400 INVALID_FIELD` for
+  a measure over a field the object does not have, `404 CUBE_NOT_FOUND` for an
+  unregistered cube). Monitoring that counted these as server faults will see the
+  5xx rate drop and a 4xx rate appear; a client that retries on 5xx will stop
+  retrying a request that could only ever fail the same way. Both are the intended
+  correction — the condition was always the caller's mistake — but they are
+  visible, so they are stated rather than buried.
+
+  **Which inputs are refused did not change.** This changes the SHAPE of the
+  error and nothing about the judgement that produced it: no refusal condition
+  was touched, no input that used to compile now refuses, and no input that used
+  to refuse now compiles. That claim is pinned input-by-input (refusals _and_
+  accepted inputs with their compiled trees) in
+  `filter-refusal-envelope.test.ts`, which is green both before and after the
+  change — only the envelope assertions move.
+
+  The message-substring list survives on purpose. All six of its entries were
+  re-verified as bare `Error`s (`dataset-compiler.ts`, `native-sql-strategy.ts`,
+  `dataset-executor.ts`, `read-scope-sql.ts`), so deleting it would regress those
+  families from `400 DATASET_INVALID` to 500. It is a placeholder for their
+  enveloping, not a second classification mechanism, and it is now documented as
+  such: a new refusal should carry a `code`/`status` and be served by the
+  envelope branch for free. The passthrough is deliberately **4xx-only** and
+  requires **both** `code` and `status`, so an internal fault can never be
+  re-labelled as the caller's fault, and this route never invents a code a
+  producer failed to supply.
+
+- e6b1bb0: fix(service-analytics): 过滤值不再被降级成字符串 —— `{code: {$eq: '007'}}` / `'null'` / `'true'` 按作者写的字面值绑定 (#5526)
+
+  analytics 的 `filter-normalizer` 内部把每个比较数(comparand)压成 `values: string[]`
+  再由消费方**猜**回类型:出口是 `stringifyForCube`,入口是 `recoverNumber` 与
+  `coerceFilterValueForSql` / `coerceFilterValueForObjectQL`。字母表是"全体字符串"、
+  解码规则是"这串看起来像不像数字/布尔/null"的编码没有任何转义机制,于是作者写的字符串
+  和编码器为其他类型写下的 token 撞车。`{code: {$eq: v}}` 在 `main` 上实测:
+
+  | 作者的 `v` | SQL 绑定          | 引擎绑定          |
+  | ---------- | ----------------- | ----------------- |
+  | `'007'`    | `7`(#5528 已修)   | `7`(#5528 已修)   |
+  | `'1.50'`   | `1.5`(#5528 已修) | `1.5`(#5528 已修) |
+  | `'null'`   | 真 NULL           | 真 `null`         |
+  | `'true'`   | `1`               | `true`            |
+
+  每一行都是一个缺陷:存着作者那种写法的 TEXT 列不再匹配。`'007'` 在 SQLite 上是
+  整数与 TEXT 列的跨类型比较、恒不相等,在 Postgres 上 `text = integer` 直接报类型错;
+  `'null'` 那一行比"空"更糟 —— 与真 NULL 的比较对任何行都是 UNKNOWN,图表永远画不出东西。
+  零填充串、当枚举码用的 `'true'`/`'false'`、当字面标签用的 `'null'` 都是真实业务形状
+  (订单号、SKU、邮编、国际长途区号)。
+
+  **修法**:`NormalizedFilterNode` 的 leaf `values` 由 `string[]` 改为 `unknown[]`,
+  作者写的值原样穿过整棵树,不再有任何东西去解码它。仅在边界真正要求时才转换:
+
+  - `toSqlBindValue`(唯一留下的转换,且是**单向**的:值 → 它的 SQL 绑定形态,不是解码器)
+    ——只处理驱动绑不了的 JS 类型:`boolean` → `1`/`0`(better-sqlite3 拒绝 JS 布尔)、
+    `Date` → ISO 文本、其他对象 → JSON 文本。它不检查任何字符串。
+  - LIKE 族的比较数被 `filter.zod.ts` 声明为 `z.string()`,所以在发射点字符串化 ——
+    与 `driver-sql` 的 `applyLike` 同一个 `String(value)`,两个面上 `$contains` 仍是一件事。
+
+  ObjectQL 引擎路径现在不需要任何转换:引擎按**存储**的运行时类型比较,而它拿到的就是
+  作者写的值。`stringifyForCube` / `recoverNumber` / `coerceFilterValueForSql` /
+  `coerceFilterValueForObjectQL` 一并删除。
+
+  两处读法作为直接后果改变了,方向都是 fail-closed:
+
+  - `{name: {$contains: null}}` 原先编译成 `LIKE '%%'` —— 匹配**每一个**非 NULL 行,
+    因为 `stringifyForCube(null)` 是 `''`;现在是 `LIKE '%null%'`,与 `driver-sql`
+    一直以来的编译结果一致。
+  - `{amount: {$gt: null}}` 原先编译成 `amount > ''`(一次针对空字符串的真实比较);
+    现在绑定 NULL,谓词为 UNKNOWN、图表画不出行 —— 无序比较数的诚实答案,也是
+    `driver-memory` / `formula` 给出的答案。(#5332 明确指出这个比较数位置没有任何裁决
+    覆盖、`''` 只是占位符;删掉编码器就按构造把它定了。)
+
+  `timeDimensions[].dateRange` 的两个边界现在按 spec 声明的类型(`string[]`)原样传递:
+  原先它们也过 `coerceFilterValueForObjectQL`,其文档宣称"epoch-ms 边界会还原成数字"——
+  那是消费方在宽容地兜一个契约并未声明的形状,和把 `'007'` 读成 `7` 是同一个猜测
+  (Prime Directive #12:epoch-ms 窗口要么在生产者、要么在 spec 里声明,不在这里猜)。
+
+  `{stage: null}` / `{$eq: null}` / `{$ne: null}` / `{$null:}` / `{$exists:}` 的空值
+  谓词语义(#5332 / #5525)不变:真 `null` 比较数编译成 `notSet` / `set`,从不进入
+  `values`。#5567 的 LIKE 转义契约不变。
+
+- a7b854f: fix(service-analytics): the three SQL compilers compare LIKE values literally (#5567)
+
+  `$contains` / `$notContains` / `$startsWith` / `$endsWith` build a `LIKE` pattern
+  around the comparand the author wrote. All three of this package's SQL compilers
+  concatenated that comparand straight into a wildcard position — no escaping, no
+  `ESCAPE` clause — so `_` (LIKE's single-character wildcard) and `%` (its
+  multi-character one) stopped being literals. Measured on real SQLite, over the
+  rows `x_admin` / `xyadmin` / `off 50% now` / `off 5012 now`:
+
+  | `where`                         | returned    | correct |
+  | ------------------------------- | ----------- | ------- |
+  | `{name: {$contains: '_admin'}}` | `['1','2']` | `['1']` |
+  | `{name: {$contains: '50%'}}`    | `['3','4']` | `['3']` |
+  | `{name: {$startsWith: 'x_'}}`   | `['1','2']` | `['1']` |
+  | `{name: {$endsWith: '0% now'}}` | `['3','4']` | `['3']` |
+
+  Every row is a **widening** — rows the author excluded came back — and
+  `$notContains` is the mirror image, excluding rows the author kept. One of the
+  three call sites is the ADR-0021 D-C read-scope (tenant + RLS) lowering, where a
+  wider predicate is over-reach rather than a loose filter (the #5347 / #5324
+  ruling on that same file). Prime Directive #3 forces machine names to
+  `snake_case`, so essentially every machine-name comparand carries a `_` and hit
+  this silently.
+
+  All three compilers now escape the comparand and bind an explicit
+  `ESCAPE` argument, matching what `driver-sql`'s `applyLike` has always done — so
+  the same filter selects the same rows whichever strategy answers, and the
+  `/analytics/sql` echo describes the statement that ran instead of a wider one.
+
+  **No authoring change.** A comparand with no `_`, `%` or `\` binds exactly the
+  pattern it bound before; only its meaning when it _does_ carry one changes, from
+  wildcard to literal. If you were relying on a comparand acting as a wildcard,
+  that was never a declared capability of these operators — the spec describes them
+  as substring / prefix / suffix matches — and `driver-sql` already read it
+  literally, so the reading you got depended on which strategy served the query.
+
+- f56ebea: fix(service-analytics): a `null` comparand in an analytics `where` is a null predicate, not `= ''` (#5332)
+
+  `{stage: null}` compiled to `stage IS NULL`, while `{stage: {$eq: null}}` — the
+  same predicate — compiled to `stage = $1` binding the empty **string**. One
+  meaning had two answers inside one file: the bare-`null` spelling took
+  `fieldLeaves`' `raw === null` branch, the operator spelling fell through to the
+  `MONGO_TO_CUBE_OP` map, and `stringifyForCube(null)` handed it `''`.
+
+  Measured before the fix, on cube `deals` / column `stage`:
+
+  | `where`                  | WHERE           | bindings |
+  | ------------------------ | --------------- | -------- |
+  | `{stage: null}`          | `stage IS NULL` | `[]`     |
+  | `{stage: {$eq: null}}`   | `stage = $1`    | `['']`   |
+  | `{stage: {$ne: null}}`   | `stage != $1`   | `['']`   |
+  | `{stage: {$null: true}}` | `stage IS NULL` | `[]`     |
+
+  The failure was **silent, not loud**: an "is empty" dashboard widget drew zero
+  rows — never an error — because a real value can never equal a NULL column, and
+  the author saw "no data" rather than anything to debug. On a text column the
+  `$ne` direction was worse than empty: in SQLite / MySQL `''` is a value rows
+  genuinely store, so "stage is not empty" compiled to `stage != ''` and excluded
+  exactly the rows it was asked to keep, while "stage is empty" returned the one
+  row that is emphatically not null.
+
+  `$eq: null` and `$null: true` are not near-synonyms to be reconciled by taste —
+  `driver-mongodb`'s translator **rewrites** the latter into the former, so they
+  are one predicate in the contract, and `read-scope-sql.ts` (this package's other
+  SQL compiler), `driver-sql`, `driver-memory` and `formula` all compile them
+  alike. This module was the one dissenting half of one package; `fieldLeaves` now
+  emits the same `notSet` / `set` leaves for all three spellings, so both
+  strategies, the ObjectQL engine filter and the `/analytics/sql` display echo
+  follow with no new cases.
+
+  The #5146 NULL-safe `$not` guard table moved in the **same** commit, because it
+  describes this file's emitter rather than a sibling's: while `$eq: null` was a
+  value comparison the guard correctly classified it as one, and left alone it
+  would have wrapped `stage IS NOT NULL AND stage IS NULL` — an always-false
+  conjunction — and negated it to **every** row for a filter meaning "stage is not
+  empty". `nullValueSatisfiesOperator` and `operatorIsNullTotal` now carry the
+  `value === null` arms their `read-scope-sql` counterparts have, and
+  `{$not: {stage: {$eq: null}}}` returns the rows the other three backends already
+  return for it.
+
+  Scoped deliberately to the two spellings `filter.zod.ts` gives a null _meaning_.
+  `stringifyForCube`'s `v == null` arm is untouched: it still serves comparand
+  positions no ruling covers (`$gt: null`, `$in: [null]`), where `''` is a
+  placeholder rather than an answer. An empty-string comparand also stays a value
+  comparison — `{stage: {$eq: ''}}` still binds `''` — since reading `''` as null
+  would be the same defect with its sign flipped.
+
+  Authoring is unchanged; only the compiled predicate is. A widget that worked
+  around the old behaviour by filtering on the literal empty string (`{$eq: ''}`)
+  keeps working and still means the empty string; one that wrote `{$eq: null}` and
+  saw nothing now gets its rows.
+
+- f522e95: fix(service-analytics): the dataset raw-SQL bridge routes by object, so datasets over non-default datasources stop reading `0` (#5033)
+
+  `AnalyticsServicePlugin`'s `executeRawSql` auto-bridge received the object name
+  and threw it away: `engine.execute(knexSql, { args: params })`. `ObjectQL.execute()`
+  picks its driver in the order `options.object` → `getDriver(object)`, then
+  `options.datasource`, then the default driver — so rule 1 could never fire and
+  **every dataset raw-SQL read landed on the default datasource**. Any object routed
+  elsewhere (the ADR-0057 §3.6 telemetry split for `lifecycle.class ∈ {audit,
+telemetry, event}`, an explicit `object.datasource`, a `datasourceMapping` rule)
+  raised `no such table`, which the widget-level graceful degradation then turned
+  into an empty result — a confident `0` over live rows, on a green dashboard.
+  Measured: `sys_audit_log` returned 49 records through the object-routed read and
+  `{"rows":[]}` through the dataset raw-SQL read, on the same running kernel.
+
+  The bridge now passes `{ args: params, object: objectName }`, matching the
+  `executeAggregate` bridge beside it (`engine.aggregate(objectName, …)`), so both
+  dataset execution paths give **one** answer to "which datasource is this object in".
+  No configuration change is needed; misrouted dashboards start reading real data.
+
+  **Behaviour change worth knowing about.** A dataset whose SQL `LEFT JOIN`s (what
+  `NativeSQLStrategy` emits for a dotted dimension such as `account.industry`) across
+  two datasources previously ran against the default datasource and silently read the
+  wrong database. It now runs on the base object's own datasource, where the joined
+  table genuinely is not — and **fails loudly** instead of degrading, because the base
+  table resolved fine and reporting it as "unavailable" would keep the confident `0`
+  alive under a new cause. The error names the actual cause and the remedy:
+
+  ```
+  [Analytics] dataset "audit_by_actor" cannot be executed as one statement:
+  table "account" is not on datasource "telemetry", which is where its base object
+  "sys_audit_log" lives — "account" is registered on the default datasource.
+  A dataset JOIN cannot cross datasources. Fix it by binding both objects to the
+  same datasource, or by dropping the cross-datasource relationship from the
+  dataset's `include`/dimensions.
+  ```
+
+  Graceful degradation is unchanged for genuine absence: a dataset whose own backing
+  object (or a joined object that this kernel never registered) has no table still
+  renders as "no data" with the existing server-side `warn`, rather than failing the
+  widget. `AnalyticsServiceConfig` gains one optional, diagnostics-only hook —
+  `getObjectDatasource(objectName)` — used solely to name the datasources in that
+  message; it never selects a driver.
+
+- fb3d99b: fix(analytics,rest)!: an RLS read-scope lowering failure is a `500`, not the caller's `400` — and its policy detail no longer reaches the response (#5367)
+
+  **Observable behaviour change — read this if you alert, retry, or assert on status.**
+  A request whose dataset carries an RLS read scope that `read-scope-sql.ts` cannot
+  lower used to answer `400 DATASET_INVALID` with the refusal message echoed
+  verbatim. It now answers `500 ANALYTICS_QUERY_FAILED` with the message withheld
+  (`"Internal server error"`); the full text goes to the server log. Monitoring that
+  counted these as client errors will see a 4xx disappear and a 5xx appear, and a
+  client retrying on 5xx will now retry a request that cannot succeed until an
+  administrator fixes the policy. Both follow from the correction below and are
+  stated rather than buried.
+
+  ## What was wrong
+
+  These ten fail-closed refusals were the last family `/analytics/dataset/query`
+  classified by **prose** — the final entry of the hardcoded message-substring list
+  #5352 introduced, which #5367's first PR had already shrunk from six entries to
+  one. Two defects in one verdict:
+
+  - **Misattribution.** `compileScopedFilterToSql(filter, alias)` receives an RLS
+    `FilterCondition` the security service compiled from an **administrator's**
+    sharing rule / permission set, and a join alias the **dataset compiler**
+    generated. Neither is caller input — the caller's own predicate goes through
+    `filter-normalizer.ts` and has answered `INVALID_FILTER` / 400 since #5352. So
+    what can arrive here is a broken policy, or drift between two of our own
+    components (#5557's `$regex` was literally the second case). For this request's
+    caller both are a **server** fault; `400` told them to fix a request that was
+    never wrong and kept the real fault out of 5xx alerting.
+  - **Disclosure.** A 400 echoed the message, so
+    `unsafe field identifier "secret_policy_field"` and
+    `unsupported operator "$regex" on "owner_email"` handed a tenant the field names
+    and comparands of the RLS policy governing them.
+
+  The maintainer ruled on 2026-08-06 (option B on #5367's decision card; option A
+  was `READ_SCOPE_INVALID` / 422, rejected because no consumer reads a code on this
+  path, a 4xx misreports a condition the client cannot fix, and 422 would have left
+  the disclosure question to be re-decided message by message).
+
+  ## What changed
+
+  - `read-scope-sql.ts` gains a module-local `readScopeCompileError` — the twin of
+    `filter-normalizer.ts`'s `invalidFilterError`, and likewise **the only way the
+    module refuses**. All ten sites carry `READ_SCOPE_COMPILE_FAILED` / **500**.
+    `:104`'s alias-vs-field split (option C on the card) collapses under B: both
+    branches answer the same verdict, pinned so the collapse is a recorded decision.
+  - `rest-server.ts` loses branch ② entirely. **The message-sniffing mechanism is
+    fully retired** — nothing in this catch reads prose any more, and #5367's
+    Prime-Directive-#12 retirement schedule ("declared, loud, tested AND removable
+    on a schedule") is paid off.
+  - The route's 5xx branch now withholds the message of any producer that
+    **declares** a server fault (`status >= 500` with a `code`). This was needed
+    rather than inherited: `looksLikeInternalErrorLeak` (#3867/#5520) is a heuristic
+    over SQL/driver _phrasing_, and measured, every read-scope message returns
+    `false` from it — so retiring the list alone would have moved the policy content
+    from a 400 body into a 500 body instead of out of the response. Teaching that
+    heuristic to recognise `[read-scope-sql]` would have been _more_ message
+    sniffing, so the rule keys on the ADR-0112 envelope instead. **Undeclared** 5xx
+    errors keep #5667's tiering, so a self-authored fault ("no strategy can handle
+    query …") stays readable.
+  - `READ_SCOPE_COMPILE_FAILED` is registered in `ERROR_CODE_LEDGER` under
+    `@objectstack/service-analytics` (ADR-0112 D3) and typed as
+    `RegisteredErrorCode` at the constructor, so an unregistered code is a compile
+    error. It is legible on the wire through the sibling `/analytics/query` exit,
+    which puts a thrown `err.code` in `error.details.code` (#3842).
+
+  **Which inputs are refused did not change.** No refusal condition moved: nothing
+  that used to lower now throws, and nothing that used to throw now lowers. That is
+  pinned input-by-input — refusals _and_ accepted read scopes with their compiled
+  SQL and bind params — in `read-scope-refusal-envelope.test.ts`, which is green both
+  before and after; only the envelope assertions move.
+
+  Coverage: `read-scope-refusal-envelope.test.ts` (service-analytics) drives all ten
+  sites through the real compiler; `analytics-read-scope-refusal-envelope.test.ts`
+  (rest) drives five policy shapes end-to-end through a real `AnalyticsService`,
+  asserting the 500, that the body contains no policy detail, and that the withheld
+  text is present in the log — plus a positive control and both sides of the
+  declared-vs-undeclared withhold.
+
+- 628b028: fix(service-analytics): thirteen caller-shaped analytics refusals answer 4xx from their own envelope instead of `500` (#5716)
+
+  **Observable behaviour change — read this if you alert, retry, or assert on status.**
+  Thirteen refusal conditions in `service-analytics` (twelve `throw` sites — the
+  cross-object measure and filter share one) used to reach the caller as
+  `500 {"code":"ANALYTICS_QUERY_FAILED"}` on `POST /analytics/dataset/query`, and as
+  `500 {"code":"INTERNAL_ERROR"}` on `POST /analytics/query`. They now answer **400** —
+  `DATASET_INVALID` for the seven that are a verdict about the dataset or the whole
+  selection, `INVALID_FIELD` for the six that name one member of the request:
+
+  | refusal                                                          | now                     |
+  | ---------------------------------------------------------------- | ----------------------- |
+  | dataset JOIN crosses datasources (#5115)                         | `DATASET_INVALID` / 400 |
+  | `include` names a relationship the object does not have          | `DATASET_INVALID` / 400 |
+  | `include` path past the 3-hop limit                              | `DATASET_INVALID` / 400 |
+  | a `dateRange` bound that is not a date                           | `DATASET_INVALID` / 400 |
+  | `compareTo` names a timeDimension with no `dateRange`            | `DATASET_INVALID` / 400 |
+  | `compareTo` with no dated window to shift                        | `DATASET_INVALID` / 400 |
+  | `compareTo` ambiguous between two dated windows                  | `DATASET_INVALID` / 400 |
+  | cube declares no such measure (#4157)                            | `INVALID_FIELD` / 400   |
+  | ObjectQL: cross-object time-dimension bucket                     | `INVALID_FIELD` / 400   |
+  | ObjectQL: cross-object measure                                   | `INVALID_FIELD` / 400   |
+  | ObjectQL: cross-object filter                                    | `INVALID_FIELD` / 400   |
+  | ObjectQL: multi-hop cross-object dimension                       | `INVALID_FIELD` / 400   |
+  | ObjectQL: non-recombinable measure over a cross-object dimension | `INVALID_FIELD` / 400   |
+
+  Monitoring that counted these as server errors will see a 5xx disappear and a 4xx
+  appear, and a client retrying on 5xx will stop retrying a request that cannot
+  succeed until the request or the dataset changes. **No refusal condition moved and
+  no message was reworded** — the same inputs are refused, in the same words; only
+  the envelope is new. (The messages are load-bearing beyond readability: #5923's
+  tests assert the `planCrossObject` wording, and #5717 tracks one compiler message
+  for colliding with a downstream sniffer.)
+
+  ## What was wrong
+
+  #5352 gave the dataset route a list of message SUBSTRINGS so six refusal families
+  could answer 400, and #5367 retired five of those entries by giving their
+  producers an ADR-0112 envelope. Both rounds worked from that list — and the list
+  was only ever the refusals someone had already hit. Reading every `throw` in the
+  package afterwards found thirteen more of exactly the same kind, which had never
+  been on it: a typo in `compareTo`, a `dateRange` the dashboard sent, a dataset
+  whose `include` names a relationship that does not exist. Each answered "the
+  platform is broken" for a mistake the caller or the author could fix, on both
+  analytics faces.
+
+  **Both faces move, measured.** `/analytics/dataset/query` reads the envelope in
+  its catch (#5352); `/analytics/query` exits through
+  `dispatcher-plugin.errorResponseBase`, which already adopts a thrown `status` and
+  carries the `code` (#3867/#3842) — so the cross-object refusals go from
+  `500 INTERNAL_ERROR` to `400 INVALID_FIELD` there as well, without touching that
+  route. The open question #5811 tracks on that face is about _withholding the
+  message of a declared 5xx_, which none of these are.
+
+  ## Why two codes
+
+  `dataset-refusal.ts` gains a second constructor, `invalidMemberError`
+  (`INVALID_FIELD` / 400 + `member`/`param`/`cube`), beside `datasetInvalidError`.
+  The split is by what the refusal is a verdict ABOUT: the dataset/selection as a
+  whole, or one member the request named. The member family is `INVALID_FIELD`
+  because the three shipped analytics gates already answer exactly that for the
+  NEIGHBOURING member-level mistakes on the same request keys — `measures` (#4437),
+  `dimensions`/`timeDimensions` (#5520), `where` (#5669) — so one class of mistake
+  keeps one wire shape; and because these six fire on `/analytics/query` too, where
+  there is no dataset for `DATASET_INVALID` to be about. No new code is registered:
+  both are already in the ADR-0112 vocabulary.
+
+  ## What deliberately did NOT change
+
+  `native-sql-strategy`'s "measure … has unrecognised type" stays a bare `Error`
+  (an undeclared 500) although #5716 listed it as author-shaped. Measured:
+  `Metric.type` is the closed `AggregationMetricType` enum, `metric-type-coverage.test.ts`
+  pins that the strategy handles every member of it, the dataset compiler writes
+  only `SUPPORTED_AGGREGATES` into a cube, and `inferMeasure` mints six known types
+  — so no spec-valid cube can reach it. An arrival is our own drift or a host
+  registering an unparsed cube, and blaming the caller would hide a platform fault
+  from 5xx alerting. The two "Cube not found" guards and the two operator-drift
+  throws stay bare for the same reason.
+
+  Coverage: `unlisted-refusal-envelope.test.ts` (service-analytics) drives all
+  thirteen refusals through the real producers — one block pinning that the refusal
+  SET and its wording are unchanged, one pinning the envelope, one pinning the
+  verdicts that stay 500; `analytics-dataset-unlisted-refusal-envelope.test.ts`
+  (rest) drives eleven of them end-to-end through the route with a real
+  `AnalyticsService`, plus three positive controls and the two sites that route
+  cannot reach (with the measurement that explains why).
+
+- b857356: fix(service-analytics): a `where` written as a `FilterArray` is lowered instead of silently dropped (#5334)
+
+  **Observable behaviour change.** An analytics query whose `where` arrived as an
+  ARRAY had its filter **deleted**: `normalizeAnalyticsFilterTree` answered every
+  array with `return null`, so no predicate was compiled, no error was raised, and
+  the widget charted the **entire dataset**. The compiled SQL stayed perfectly
+  valid — just broader than the author asked for — which is why it was invisible
+  to every test that asserts a SQL string. The issue's own measurement:
+  `generateSql({cube:'deals', measures:['total'], dimensions:['id'], where:
+[['stage','=','won']]})` emitted `SELECT id AS "id", COUNT(*) AS "total" FROM
+"deal" GROUP BY id` with an empty `params`. It now emits the bound `WHERE` and
+  returns the two won deals.
+
+  `FilterArray` (`['stage','=','won']`, `['and', […], […]]`, `[[…], […]]`) is
+  INPUT-ONLY authoring sugar (#5285), and #5158's ruling C says every door into
+  the runtime lowers it through the single `parseFilterAST` sink before anything
+  downstream sees a filter. #5329 closed ObjectQL's six entry points that way and
+  deleted the four drivers' private array dialects. Analytics is the **fifth
+  door**: it compiles `where` itself — to SQL (`NativeSQLStrategy`) or to a
+  `FilterCondition` for the engine (`ObjectQLStrategy`) — so nothing upstream
+  lowers for it. It now gives the same three answers the engine door gives:
+
+  - `[]` — "no filter", not a failed filter: no predicate, no error (unchanged).
+  - A well-formed `FilterArray` — **lowered** through `parseFilterAST`, so both
+    spellings of one filter select the same rows on both strategies.
+  - Any other non-empty array — **refused** with `INVALID_FILTER` / 400
+    (ADR-0112), the envelope the drivers' `filterArrayReachedDriverError` uses.
+    This is where the undeclared INFIX form (`[condA, 'or', condB]`) lands, and
+    where a list of `FilterCondition` objects (`[{stage:'won'}]`) lands — neither
+    is a `FilterArray`, `parseFilterAST` has no lowering for either, and dropping
+    them is what returned the unfiltered dataset.
+
+  Lowering rather than refusing keeps one dashboard's metadata meaning one thing:
+  the same `where` on a plain `find()` already lowers at the engine door, so
+  refusing it here would have forked the product by which face read the metadata.
+
+- fce4c73: fix(service-analytics): an analytics `where` over a missing field answers 400 INVALID_FIELD, not a driver 500 (#5669)
+
+  `ensureCube` carried two source-field gates — `assertMeasureFields` (#4437,
+  `param: 'measures'`) and `assertDimensionFields` (#5520,
+  `param: 'dimensions' | 'timeDimensions'`) — and none for the filter face, the
+  request key most likely to carry a hand-typed field name. A `where` naming a
+  field the object does not have compiled straight into the statement and came
+  back as a driver error with no envelope:
+
+  ```
+  POST /analytics/query {"cube":"crm_account","measures":["count"],"where":{"bogus_col":"x"}}
+  → SELECT COUNT(*) AS "count" FROM "crm_account" WHERE bogus_col = $1
+  → 500 {"code":"SQLITE_ERROR","message":"Internal server error"}
+
+  # the control group on the same route, already fixed by #4437 / #5520
+  POST /analytics/query {"cube":"crm_account","measures":["count"],"dimensions":["bogus_dim"]}
+  → 400 {"code":"INVALID_FIELD","message":"Dimension 'bogus_dim' … "}
+  ```
+
+  A driver error class as the caller's `error.code` for a caller-shaped mistake is
+  the ADR-0112 fault #4437 was filed about; the `/data` route has answered the same
+  typo with a field-naming 400 since #4315/#4254.
+
+  **The gate.** `ensureCube` now runs `assertWhereFields` after the other two on
+  every path, so a filter whose source column the backing object does not have is
+  refused **before** any SQL is built, with the same envelope its two siblings
+  use: `INVALID_FIELD` / 400 plus `field` / `object` / `param: 'where'`, and a
+  message naming the field, the valid filter members and the object's known field
+  list. `query`, `generateSql` and `queryDataset` (both `runtimeFilter` and a
+  dataset's own declared `filter`) are covered, and a rejected query leaves
+  nothing behind in the cube registry. `/analytics/dataset/query` needed no
+  change: #5352's envelope branch already carries a coded 4xx through, which the
+  new REST-face test pins end to end.
+
+  **Field names come from the SQL producer's own reader.** The members are
+  collected through `normalizeAnalyticsFilterTree` + `collectFilterLeaves` — the
+  same pair both strategies call to build the predicate — rather than by walking
+  the raw `where` object. So `$and`/`$or`/`$not` nesting, `$`-prefixed operator
+  keys, `$between` lowering, the `{owner: {region: 'NA'}}` → `owner.region`
+  flattening and the #5334 array spelling are all read exactly as they will be
+  compiled, in one place, instead of in a second walker that could drift from it.
+
+  **What deliberately did not change:**
+
+  - Filtering on a REAL field the cube never declared (`where: {phone: '555'}`)
+    still works — the gate asks "does the _object_ have this field", never "did the
+    cube declare it".
+  - A filter member resolves through `cube.dimensions` **and** `cube.measures`,
+    which is what the strategies do: a cube declaring
+    `measures.revenue = {sql: 'annual_revenue'}` still answers
+    `where: {revenue: {$gt: 100}}` as `annual_revenue > ?`.
+  - A declared member is followed to its real column, so a dimension `assessed`
+    over column `assessed_at` is not judged by its own name.
+  - `id` / `created_at` / `updated_at` stay admitted unconditionally, matching the
+    data path's `resolveQueryFields`.
+  - An expression `sql` (on the cube or on a member), a dotted relation traversal,
+    and a host that wires no field-name probe are all stood down on, exactly as the
+    measure and dimension gates stand down.
+  - The `INVALID_FILTER` family is untouched. A `where` the normalizer refuses
+    outright — an unknown operator, a zero-operator field constraint, an
+    unlowerable filter array — is _not_ judged here: the gate stands down and the
+    refusal stays where it already happens (#5352 / #5367's geography). A field
+    gate that cannot read the tree has nothing to say about it, and pulling those
+    refusals forward would also have newly refused them on the draft-preview path,
+    whose matcher never consults the normalizer.
+
+- f6385c7: fix(service-analytics): a `timeDimensions` entry used only as a date WINDOW no longer buckets the grid (#5688)
+
+  **Observable behaviour change — read this if you render, page, or assert on
+  dataset responses.** A selection that used a date dimension only as a window —
+  `timeDimensions: [{ dimension, dateRange }]` with no `granularity`, and the
+  dimension NOT listed in `selection.dimensions` — used to have the dataset
+  dimension's declared `dateGranularity` filled in anyway. That made the entry a
+  `GROUP BY` item, so the response grew a time column nobody selected and every
+  row split per bucket. "Count by Owner" plus a dashboard date-range filter came
+  back as "by Owner × month":
+
+  ```
+  before  fields  [owner, close_date, opp_count]
+          rows    [{owner:'u1', close_date:'2026-01', opp_count:1},
+                   {owner:'u1', close_date:'2026-02', opp_count:1},
+                   {owner:'u2', close_date:'2026-01', opp_count:1}]
+
+  after   fields  [owner, opp_count]
+          rows    [{owner:'u1', opp_count:2},
+                   {owner:'u2', opp_count:1}]
+  ```
+
+  Both the **row count and the column set** change for such a selection: the extra
+  month column disappears and rows that were split per bucket collapse back into
+  one row per selected dimension tuple. A KPI single-value card that was reading
+  the first of several month rows now reads the only row. Consumers that pinned
+  the previous shape (a snapshot of `fields`, a row count, a hard-coded column
+  index) need updating; consumers that render the response's own `fields` do not.
+
+  Three conditions had to hold together to be affected, so a selection outside
+  them is byte-identical: the dataset dimension declares an explicit
+  `dateGranularity`, the `timeDimensions` entry states no `granularity`, and
+  `selection.dateGranularity` is unset.
+
+  **What still buckets, unchanged.** An entry is bucketed when the request says
+  that date is being bucketed: the dimension is one of the selection's own
+  `dimensions`, the entry carries its own `granularity` (#4033 — still projected
+  as a column even when not selected), or `selection.dateGranularity` is set. The
+  granularity _precedence_ chain is untouched. A dataset dimension's
+  `dateGranularity` says how that date renders **when** grouped — it is no longer
+  read as a request to group by it.
+
+  **`compareTo` alignment (#3588/#4870) holds by construction.** The comparison
+  pass re-enters the same query builder with the same grid dimensions, differing
+  only in the shifted `dateRange`, so both passes bucket an entry alike or not at
+  all — never one of each, which was the state that left every `__compare` column
+  empty. For a window-only anchor this **repairs** the comparison rather than
+  preserving it: the merge has always keyed on `selection.dimensions` alone, so
+  the backfilled bucket column sat outside the merge key, and with several
+  month-split rows per group the comparison value landed on whichever row the
+  index held last while the others read a confident `0`.
+
+  Also fixed, same root cause: a time column that IS projected via
+  `timeDimensions` (an entry carrying its own `granularity`, never listed under
+  `dimensions`) now carries its dataset `label` in `fields` instead of a bare
+  `type` — the label enrichment walked `selection.dimensions` only.
+
+- 8dbd2a8: fix(service-analytics): dataset 响应的 `fields` 在「度量全部自带 filter」的路径上也描述维度列 (#5537)
+
+  一个 dataset 查询,只要它的**基础度量全部带有自身的 `filter`**(或它选中的 derived
+  度量的依赖全部如此),响应里的 `fields` 就只剩度量列,被选中的维度**完全没有描述符**。
+  维度值一直都在 `rows` 里(它就是合并键),但读取列元数据的消费者拿不到维度列的
+  `label` 与 `type`,只能退回去 humanize 原始行键。
+
+  HotCRM「Sales Performance」上肉眼可见:同一个声明了 `label: 'Owner'` 的 `owner` 维度,
+  "Open Pipeline by Owner"(度量无 filter)表头是 `Owner`,而 "Win / Loss by Rep"
+  (`won_count`/`lost_count` 各带 filter、`win_rate` 是 ratio)表头是小写 `owner`。
+  换成字符串维度 `lead_source` 看起来正常纯属巧合 —— humanize 后恰好等于真 label;
+  两种维度的描述符其实都丢了。
+
+  根因在网格装配处,不在渲染端:`DatasetExecutor.runMeasurePass` 只有在存在**无 filter**
+  度量时才发那条主查询;当每个基础度量都自带 filter 时,它从 `{ rows: [], fields: [] }`
+  起步,而随后每个补充子查询只追加一个**度量**描述符。现在这种情况下,维度描述符取自
+  **第一个补充子查询自己的结果** —— 它 group by 的维度与整个网格完全一致 —— 因此两条路径
+  的 `fields` 形状(维度在前、顺序、`type`)按构造收敛,而不是靠 executor 再抄一份
+  「哪些维度被投影」的规则(该规则的单一事实源在各 strategy 的 `buildFieldMeta`,#4033)。
+
+  `compareTo`、`totals` 与 derived 度量都经由同一条 pass,所以一并修好。
+
+  已知的相邻缺口**不在**本次修复范围,单独立了 #5688:一个只带 `dateRange` 的
+  `timeDimensions` 条目会被补上 dataset 的默认粒度,于是「窗口」变成第二层 GROUP BY,
+  网格被按月拆分、并多出一个没人选过的时间列(该列在 `fields` 里也拿不到 `label`)。
+  它在两条路径上表现一致(本次修复前后皆然),且修它会改变响应形状,故不搭车。
+
+- 88a6bed: fix(service-analytics): an ad-hoc cube's dimensions no longer depend on how the `where` was spelled (#5353)
+
+  `inferCubeFromQuery` mints a Cube for a free-form analytics query that names no
+  registered cube, seeding `dimensions` from the fields the query mentions — its
+  `measures`, `dimensions`, `timeDimensions`, and its `where`. The `where` arm was
+  guarded by `!Array.isArray(query.where)`, written when an array `where` was not a
+  filter. #5334 made it one, so from then on one filter minted two different cubes
+  depending on its spelling:
+
+  ```
+  where: {stage: 'won'}          → dimensions: {stage}   ← seeded
+  where: [['stage','=','won']]   → dimensions: {}        ← skipped
+  ```
+
+  The `where` is now LOWERED to its canonical `FilterCondition` before its keys are
+  read, so the spelling stops mattering. The lowering is the same one the
+  strategies already use (#5334's `parseFilterAST` call, extracted from
+  `normalizeAnalyticsFilterTree` as `lowerAnalyticsWhere` so there is still exactly
+  one of it), and the keys are read through `conjunctFieldKeys`, which descends
+  `$and` — necessarily, because the lowering itself introduces `$and` where the
+  object spelling has none: `[[a,…],[b,…]]` lowers to `{$and: [{a…},{b…}]}`. As a
+  result an explicit `{$and: […]}` object `where` now also seeds its conjuncts'
+  keys, which it never did.
+
+  `$or` / `$not` are not descended, and contribute no key on either spelling, as
+  before.
+
+  **No compiled statement, bound value or gate verdict changes.** Both spellings
+  already compiled a byte-identical predicate (which is why this shipped as an
+  observation rather than a defect): `resolveFieldSql` falls back to the bare
+  column name for an undeclared member, and `qualifyAndRegisterJoin` leaves bare
+  columns bare on a cube with no `joins` — which an inferred cube never has. So the
+  newly-declared dimensions move those members from the undeclared branch to the
+  declared one and both yield the same column. What does change is the suggestion
+  list in a rejection: `Valid filter members:` / `Valid dimensions:` now read the
+  same for both spellings of one filter, and `getMeta` reports the same dimension
+  vocabulary for both.
+
+  **Still spelling-dependent: a DOTTED `where` key.** `{'owner.region': 'NA'}`
+  seeds the stripped tail `region` as a base-table dimension; the array spelling
+  `[['owner.region','=','NA']]` seeds nothing and compiles the relation traversal.
+  Unifying them is #5739's call, not this change's — propagating the mint to the
+  array spelling turns a working traversal into a base-column filter over different
+  rows (and a `400 INVALID_FIELD` where the base table has no such column), while
+  withdrawing it from the object spelling would split a verdict #5740 deliberately
+  shares with the `dimensions` request key. Dotted keys therefore keep today's
+  per-spelling answer, pinned by tests, until #5739 rules.
+
+- a6b3ee7: fix(service-analytics): 即席推断的 Cube 把 `owner.region` 当成关系穿越,不再铸成基表列 `region` (#5739)
+
+  `inferCubeFromQuery` 为「没有注册 Cube 的自由查询」即席合成一个 Cube,并从查询提
+  到的字段里播种 `dimensions`。每个铸造点都先把成员过一遍 `stripPrefix` —— 一个把
+  **任何**点号名的首段剥掉的判定。对 `<cube>.` 限定符(`crm_account.industry` →
+  `industry`)这是对的;对**关系穿越**则不是:`owner.region` 被铸成
+  `dimensions.region = { sql: 'region' }`,一个**基表列**。下游 `lookupMember` 的
+  「plain second-segment」那一档随即命中它,**赶在**「synthetic relation traversal」
+  那一档把点号路径交给 JOIN 机制之前就返回了 —— 关系穿越被基表列遮蔽。
+
+  危害分两档,而更糟的是安静的那一档。当基表**恰好有同名列**时(`crm_account` 自己
+  就有 `region`),四个组合全部静默通过、无任何拒收:
+
+  ```
+  ① ObjectQL,  where: {'owner.region':'NA'} → executeAggregate 收到 {"region":"NA"}
+  ② NativeSQL, where: {'owner.region':'NA'} → … FROM "crm_account" WHERE region = $1
+  ③ ObjectQL,  dimensions: ['owner.region'] → groupBy: ["region"]
+  ④ NativeSQL, dimensions: ['owner.region'] → SELECT region AS "owner.region" … GROUP BY region
+  ```
+
+  行数与图表都是错的,而没有任何错误可读 —— ④ 尤甚:响应列名标着 `owner.region`,值
+  却来自基表,读者无法从结果里看出来。基表**没有**同名列时则落到 `400 INVALID_FIELD`
+  且点名 `region`,而调用方写的是 `owner.region`。
+
+  维护者 2026-08-06 裁定(issue #5739):即席路径**支持**关系穿越。铸造改为**原样**
+  (`dimensions['owner.region'] = { sql: 'owner.region' }`),真正的 `<cube>.` 限定
+  前缀(首段 == cube 名)仍然剥。这同时收敛了一处早有的分叉:同一个过滤器写成数组
+  (`[['owner.region','=','NA']]`)时铸不出 dimension,于是一直走 synthetic 档、一直
+  编出正确的 JOIN —— 两种写法现在逐字生成同一条语句。
+
+  **Observable behaviour change —— 若你按状态码告警/重试,或消费即席 cube 的元数据,
+  请读这一段。**
+
+  - **对象写法的点号 member 从「静默错列」/「`INVALID_FIELD` 指错名」变为 JOIN 穿越。**
+    NativeSQL 上 `where: {'owner.region': 'NA'}` 与
+    `dimensions: ['owner.region']` 现在编出
+    `LEFT JOIN "owner" ON "crm_account"."owner" = "owner"."id"` 并按 `"owner"."region"`
+    筛选/分组;此前它们筛/分组的是基表 `region`(有同名列时),或以
+    `400 INVALID_FIELD "constrains field 'region'"` 被拒(无同名列时)。**同一个请求
+    现在返回的行可能与此前不同 —— 此前那些行是错的。**
+  - **ObjectQL 上同一个 member 改为响亮拒收或正确穿越,不再有第三种更安静的答案。**
+    `where` 得到 `cannot evaluate a cross-object filter ("owner.region")` —— 与**已
+    注册 cube** 上的既有答案逐字一致;`dimensions` 走 FK-expand 正确穿越,返回关联对象
+    的值。带 `granularity` 的跨对象 `timeDimensions` 得到
+    `cannot bucket a cross-object time dimension`。
+  - **即席 cube 的 `dimensions` 词汇表里现在出现点号键**(`getMeta` 上是
+    `crm_account.owner.region`)。此前该穿越要么以剥掉的尾段出现(`crm_account.region`),
+    要么(数组写法)完全不出现。
+  - **不变的部分**:真正的 `<cube>.` 限定符照旧剥除;裸列名照旧是基表列(基表自己的
+    `region` 仍可作为 `region` 分组);#4437 / #5520 / #5669 三道源字段闸门的代码一行未
+    动,它们对裸名拼错的 `400 INVALID_FIELD` 拒收原样保留;点号 **measure**(如
+    `total.sum`)仍按 #4437 的 `400 INVALID_FIELD` 拒收 —— `lookupMember` 的 synthetic
+    穿越档是 dimension-only,dotted measure 没有可收敛的穿越答案。
+
+- ff39e63: fix(service-analytics): 维度合并键不再把「未分配」并进「空白」,并改为长度前缀消歧 (#4821)
+
+  `mergeByDimensions` 是每一份多查询 dataset 结果的装配缝:主查询与每个带 `filter`
+  的 measure 的补充子查询在这里对齐,`compareTo` 窗口自 #4870 起也按 measure 扇出后
+  经由同一个缝合并回来。这里一次键碰撞不会报错 —— 一个分组静默吸走另一个分组的数字,
+  网格仍然保持看起来合理的行数和列数。
+
+  **#4821 报告的机制与实际的缺陷不完全一致,先把这一点说清楚。** 原键是
+  `String(row[d] ?? '')` 以一个**直接写进源码的裸 U+0001 字节**相连。裸控制字符渲染
+  为空,所以 issue 正文读到的是 `join('')`,其头号复现(`['ab','c']` 与 `['a','bc']`
+  同键为 `"abc"`)其实并不成立 —— 分隔符一直在,只是看不见。真正咬人的是另外两条:
+
+  - `?? ''` 让**真正为 null** 的维度与**空字符串**维度键成同一个值。于是「未分配」被
+    并进「空白」:一行吞掉另一行的 measure,另一行的列则整个缺失 —— 而 #4708 的空组
+    填充随后会给它填上一个理直气壮的 `0`。一个真实计数为 3 的分组因此显示为 0。
+  - 单字符分隔符只在「没有任何维度**值**包含该字符」时才无歧义。维度值是用户数据
+    (文本字段、导入记录),所以那是一个假设而非保证,且一旦不成立同样静默。
+
+  **改法:长度前缀 + 显式空值哨兵。** 每段编码为 `<长度>:<值>`,`2:ab1:c` 与
+  `1:a2:bc` 对任意输入都不同,不再保留任何字符、也不再有看不见的字节留给下一个读者
+  误读(本 issue 正是这样被误读出来的)。null/undefined 单独走一个哨兵段,与消歧这件
+  事解耦。
+
+  **逐段的 `String()` 强制被刻意保留**,这与一文件之隔的 `cross-object-rebucket.ts`
+  的 JSON 键不是同一笔交易:后者重新分桶的是**同一个查询**的行,一列只有一种类型,
+  JSON 在那里免费且能换来真实的区分(空桶 `null` vs 字面量字符串 `"null"`)。本函数
+  做的是相反的事 —— 跨**不同查询**对齐行,而驱动确实会对同一个分组返回不同的 JS 类型
+  (本文件 `compareValues` 的注释即记着 "numeric strings, which is how some drivers
+  return SUM results")。改用 `JSON.stringify` 会把 `1` 与 `"1"` 渲染成两个键,让今天
+  能正确合并的行不再合并 —— 用一个新的静默缺陷换掉旧的,不算修好。该行为已有回归钉
+  测试锁住。
+
+  仅影响内部合并键,响应中的任何值都不改变。
+
+- 2cca98b: fix(service-analytics): 分析查询的 RLS read scope 不再被 `{ $not: {} }` 整表放行,`$not` 改为 NULL-safe
+
+  **这是一次安全相关的行为变更,涉及分析查询的可见行集合。请读完再升级。**
+
+  ### 变更一(要害):`{ $not: {} }` 的 read scope 以前**完全不加 WHERE**,整表可见;现在是零行
+
+  `read-scope-sql.ts` 是 RLS / 租户 read scope 降解成 SQL 的**唯一**通道(ADR-0021 D-C),
+  被 `NativeSQLStrategy.applyReadScope` 与 `ObjectQLStrategy` 用来给分析查询加可见性约束。
+  它以空字符串表示「无约束」(布尔常量 TRUE)。`compileNode({})` 返回空串,于是:
+
+  ```
+  compileNode({}) → ''  →  if (inner) 为假  →  $not 不产出任何子句
+                        →  compileScopedFilterToSql 返回 ''
+                        →  applyReadScope 的 `if (!sql) return;` 接手
+                        →  生成的 SQL 里没有 WHERE
+  ```
+
+  一条语义为 `NOT TRUE ≡ FALSE`(**什么都不给看**)的 read scope,实际效果是**整张表都给看**。
+  同一段循环里 `$and` / `$or` 的空数组一直是 fail-closed 抛错的,只漏了 `$not` 这一格。
+
+  修复后 `{ $not: {} }` 编译为恒假子句 `1 = 0`,`applyReadScope` 照常拼进 WHERE,返回零行 ——
+  与 driver-sql 在 #5134 / PR #5243 上的口径一致。
+
+  **升级影响:** 如果你的 RLS 策略(或 `cel-to-filter.ts` 降解出的 CEL 规则)在某条路径上
+  产出过 `{ $not: {} }`,该对象的分析查询此前是**无边界**的,现在会返回零行。行数从「全部」
+  掉到「零」不是本次引入的收紧,而是那条策略本来就该有的答案 —— 请核对策略本身。
+
+  同源、方向相反的一处一并修正:`$or` 的空析取项 `{}` 以前被 `.filter(s => s.length > 0)`
+  丢掉,`{ $or: [{}, { a: 1 }] }` 收紧成 `a = 1`。`{}` 是 TRUE 析取项,TRUE 吸收整个析取,
+  所以现在整条 `$or` 为 TRUE(无约束)。被丢弃分支的绑定值同时被丢弃 —— 否则 `params` 里
+  会留下没有 `?` 消费的值,把后面每一个占位符都错位到别人的值上。
+
+  ### 变更二:`$not` 改为 NULL-safe
+
+  SQL 是三值逻辑,`WHERE` 只保留 TRUE,所以裸 `NOT ("t"."stage" = ?)` 会把 `stage IS NULL`
+  的行整批丢掉;`driver-memory`、`formula` 以及 #5296 之后的 `driver-sql` 都**返回**这些行。
+  同一条 read scope,普通查询与分析查询给出不同的可见集合。#5146 已由维护者判定以 JS 家族的
+  答案为准,本次把这个编译器对齐过去 —— 它是仓内最后一个按三值逻辑回答 `$not` 的 SQL 家族实现。
+
+  `$not` 的操作数在取反前先被改写成**全域(total)谓词**:
+
+  ```sql
+  -- 之前
+  NOT ("t"."stage" = ?)
+  -- 现在
+  NOT (("t"."stage" IS NOT NULL AND "t"."stage" = ?))
+  ```
+
+  守卫**下推到每个叶子**而不是挂在 `NOT` 旁边:操作数一旦嵌套(`$not` 里套 `$or`),顶层的
+  `OR col IS NULL` 会把 JS 家族排除的行重新放进来。守卫方向**逐算子**判定,不是一刀切 ——
+  `{ $not: { a: { $ne: 5 } } }` 语义是「a 就是 5」,无条件加 `OR a IS NULL` 会把 scope 排除的
+  行交回去,正是本次要避免的静默放松。所以 `$ne` / `$nin` / `$notContains` 用
+  `col IS NULL OR (…)`,`$eq` / `$in` / `$gt` / `$between` / `$contains` 一族用
+  `col IS NOT NULL AND (…)`,而 `$null` / `$exists` / `$eq: null` / `$ne: null` 本就是全域谓词,
+  一个字节都不加。
+
+  **升级影响:** 形如 `{ $not: { stage: 'won' } }` 的 read scope,以前**不返回** `stage` 为
+  NULL 的行,现在**返回**它们 —— 分析查询的行数与图表数值会随之变化。这是把分析侧对齐到其余
+  后端,不是新增的放宽。
+
+  ### 不变的部分
+
+  `$not` 路径以外一个字符都没动:普通比较仍然编译成原样的 SQL。fail-closed 的全部保证原封不动
+  ——未知算子、嵌套关系值、裸数组、不安全标识符、非 filter 节点的 `$not` 操作数,以及
+  `$and: []` / `$or: []` 的空组合子(那一格是 #5322 的独立裁定)统统照旧抛错。
+
+- 07f1822: fix(service-analytics): read scope 的 `$ne` / `$nin` / `$notContains` 改为 NULL-safe,与写侧 `check` 对齐
+
+  **这是一次安全相关的行为变更,涉及分析查询的可见行集合。**
+  read scope 里的 `{ stage: { $ne: 'won' } }` 以前**不返回** `stage IS NULL` 的行,
+  现在**返回**它们。`$nin` / `$notContains` 同理。
+
+  `read-scope-sql.ts` 是 RLS / 租户 read scope 降解成 SQL 的唯一通道(ADR-0021 D-C)。
+  它此前把这三个算子编译成裸的 `col <> ?` / `col NOT IN (…)` / `col NOT LIKE ?`,
+  而 SQL 是三值逻辑:被比较列为 NULL 时谓词是 UNKNOWN,`WHERE` 只保留 TRUE,于是
+  「该列没有值」的行被整批丢掉。
+
+  **为什么必须与 `driver-sql` 同一个 PR 落地,而不是排到下一批。** 同一条 RLS 规则被
+  写一次、在**两侧**求值:读路径由本文件降解成 SQL,写路径由 `formula` 的
+  `matchesFilterCondition` 逐记录求值。`formula` 一直用两值 JS(`undefined !== 'won'`
+  为真)返回这些行。只对齐其中一侧,得到的不是「更小的修复」,而正是那个缺陷本身 ——
+  一条权限规则准入两个不同的行集,写侧允许的记录读侧看不见。
+
+  ```sql
+  -- 之前
+  "t"."stage" <> ?
+  "t"."stage" NOT IN (?)
+  "t"."stage" NOT LIKE ? ESCAPE ?
+  -- 现在
+  ("t"."stage" IS NULL OR "t"."stage" <> ?)
+  ("t"."stage" IS NULL OR "t"."stage" NOT IN (?))
+  ("t"."stage" IS NULL OR "t"."stage" NOT LIKE ? ESCAPE ?)
+  ```
+
+  括号不是排版:`compileField` 用裸 `AND` 连接同一字段的多个算子,不加括号的
+  `col IS NULL OR …` 会比那个 AND 结合得更松,从而**静默放宽整条 scope**。
+
+  与 `driver-sql` 一样统一用 OR 展开而非方言等价物(`NOT LIKE` 没有对应形式;SQLite
+  写法依赖本仓不锁定的引擎版本;实测执行计划相同)。正向比较逐字符不变,
+  `$ne: null` 仍是 `IS NOT NULL`(空值谓词,不是比较)。
+
+  `$not` 路径的逐叶守卫(#5146 / #5326)按原样保留,两条路径读同一张极性表。
+  `filter-normalizer`(Cube 面)不在本次范围内,归本裁决第二批。
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [b746aa0]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [d9971d3]
+- Updated dependencies [eb3e650]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [46365ab]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [c5adfe1]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/core@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Major Changes
diff --git a/packages/services/service-analytics/package.json b/packages/services/service-analytics/package.json
index 282c2ad765..d84361a35c 100644
--- a/packages/services/service-analytics/package.json
+++ b/packages/services/service-analytics/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/service-analytics",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "Analytics Service for ObjectStack — implements IAnalyticsService with multi-driver strategy pattern (NativeSQL, ObjectQL, InMemory)",
   "type": "module",
diff --git a/packages/services/service-automation/CHANGELOG.md b/packages/services/service-automation/CHANGELOG.md
index c0a995a2b8..93b4816ec9 100644
--- a/packages/services/service-automation/CHANGELOG.md
+++ b/packages/services/service-automation/CHANGELOG.md
@@ -1,5 +1,698 @@
 # @objectstack/service-automation
 
+## 17.0.0-rc.4
+
+### Major Changes
+
+- 4845f85: **The retry policy's last two dialects converge** (#4964 `flow.errorHandling`, #4962
+  `ETLPipeline.retry`).
+
+  #4661 converged the retry policy onto one declaration. It converged the two shapes that
+  published the **same exported name** (`RetryPolicy` from `./automation` and `./system` —
+  the #4411 trap), because that is the question the dual-source instrument asks. Two more
+  encodings of the identical concept were outside its vision _by construction_: both are
+  anonymous inline `z.object`s nested in a bigger schema, with no exported name to collide.
+
+  The cost of the gap fell on the author who did the right thing. `shared/retry-policy.zod.ts`
+  tombstoned `retryDelayMs` and told them to write `backoffMs` — and `flow.errorHandling`
+  then **rejected** `backoffMs` and demanded `retryDelayMs`. Reading the newer file was
+  punished, and which file an AI author reads first is arbitrary.
+
+  All four surfaces — `job.retryPolicy`, a `try_catch` node's `retry`, `flow.errorHandling`
+  and an ETL pipeline's `retry` — now build from one shared shape.
+
+  ## FROM → TO
+
+  ### `flow.errorHandling` (#4964)
+
+  |                                                                   | FROM                                | TO                                                                       |
+  | ----------------------------------------------------------------- | ----------------------------------- | ------------------------------------------------------------------------ |
+  | base delay                                                        | `retryDelayMs`, min 0, default 1000 | **`backoffMs`**, min 0, default 1000                                     |
+  | `maxRetries` / `backoffMultiplier` / `maxRetryDelayMs` / `jitter` | _(already identical)_               | unchanged                                                                |
+  | `strategy`                                                        | `'fail' \| 'retry' \| 'continue'`   | unchanged — it selects _whether_ the policy runs, so it stays outside it |
+
+  One key, one word, no default changes. Every other key, bound and default already
+  matched the converged policy, which is exactly why the divergence survived a release:
+  it looked reviewed.
+
+  ### `ETLPipeline.retry` (#4962)
+
+  |                     | FROM                                           | TO                                        |
+  | ------------------- | ---------------------------------------------- | ----------------------------------------- |
+  | count               | `maxAttempts`, min 0, **default 3**, unbounded | **`maxRetries`**, 0–**10**, **default 0** |
+  | base delay          | `backoffMs`, default **60000**                 | `backoffMs`, default **1000**             |
+  | `backoffMultiplier` | _(absent)_                                     | ≥1, default 1                             |
+  | `maxRetryDelayMs`   | _(absent)_                                     | default 30000                             |
+  | `jitter`            | _(absent)_                                     | default false                             |
+
+  ## What you must change
+
+  **1. Rename `retryDelayMs` → `backoffMs`** in any `flow.errorHandling` block. The value
+  (milliseconds before the first retry) is unchanged. The old spelling is **tombstoned**,
+  not deleted, so it rejects with the rename rather than being silently stripped, and
+  `os migrate meta --from 16` (the `retry-policy-converged` conversion, now with a
+  flow-level branch) rewrites it for you.
+
+  **2. Rename `maxAttempts` → `maxRetries`** in any `ETLPipeline.retry` block. **The number
+  does not change** — both counted the retries _after_ the initial attempt. Do **not**
+  subtract one: that adjustment belongs to `integration/connector.zod.ts`'s
+  identically-spelled `RetryConfig.maxAttempts`, which _includes_ the first attempt and is
+  deliberately **not** part of this convergence.
+
+  **3. If an ETL pipeline relied on the implicit retry count, write it out.** `retry: {}`
+  used to mean three re-runs 60s apart; it now means **none**. State `maxRetries: 3` (and
+  `backoffMs: 60000` for the old delay) to keep the old behaviour.
+
+  ## Why the ETL default flips to 0
+
+  Not merely to follow #4661. An ETL destination is a foreign system _by definition_ — a
+  warehouse, an API, someone else's database. A silent retry against a non-idempotent
+  destination is a **duplicate write**: a second invoice, a second export, a second
+  webhook. Default 0 makes retrying something an author states, and thereby claims
+  idempotency for. An unstated key is precisely where LLM-authored metadata hides this.
+
+  ## Migration surface
+
+  **`flow.errorHandling`** is live: `service-automation`'s `retryExecution` reads the key
+  (it now destructures `backoffMs`), and the D2 conversion covers stored and authored
+  flows, so no deployed stack changes behaviour.
+
+  **`ETLPipeline.retry` has an empty migration surface today, and that is why now was the
+  moment.** `etl.zod.ts` has no parse site in objectstack / objectui / cloud (批 12's
+  measurement) and an ETL pipeline is not a `defineStack` collection, so there is no stored
+  document a conversion could walk — it deliberately gets a tombstone and **no** D2 step,
+  rather than a walker advertising coverage that does not exist. Once an ETL engine lands,
+  flipping this default stops being a schema edit and becomes a behaviour change to every
+  deployed pipeline.
+
+  ## Also
+
+  The two automation retry surfaces now carry the **same** curated unknown-key table, so an
+  author learns one lesson instead of two, and `retry-policy.test.ts` gains a
+  concept-level guard: all four surfaces are asserted to expose the same key set and the
+  same defaults, by parse rather than by inspecting how each obtains them. Adding a fifth
+  retry surface without wiring it to the shared shape now fails a test — which is the check
+  that would have caught both of these issues, and the one the name-based scan could never be.
+
+### Minor Changes
+
+- 168f60f: feat(spec,automation): `update_record` / `delete_record` can declare bulk intent with `multi` (#5393)
+
+  A flow could not express "write every row this filter matches" — at all, from
+  any app. `UpdateRecordConfigSchema` / `DeleteRecordConfigSchema` are
+  `strictObject`s and neither declared any spelling of bulk intent (`multi`,
+  `bulk`, `all` and `options.multi` were each rejected as an unrecognized key),
+  and the CRUD executors never passed `options.multi` to the data engine. The
+  engine accepts a write only when `where.id` is a **scalar** or `options.multi`
+  is truthy, and throws otherwise — so a predicate `update_record` /
+  `delete_record` was unreachable, while the node descriptors advertised
+  `Delete Records` / "Delete records matching a filter." Declared ≠ enforced
+  (Prime Directive #10); the symptom was #5225's showcase sweep flow, which had
+  never deleted a record.
+
+  **New authorable key — `multi` (boolean, default `false`), on `update_record`
+  and `delete_record`.** One name for one concept (PD #12): `multi` is what the
+  data engine has always called it (`EngineUpdateOptions.multi` /
+  `EngineDeleteOptions.multi`), so the word is the same from node config to
+  driver call and greps end to end.
+
+  ```ts
+  // before — refused by the engine at run time, with no authoring-time signal
+  { type: 'delete_record', config: { objectName: 'lead', filter: { stage: 'stale' } } }
+
+  // after — the declaration makes the intent explicit and the write reachable
+  { type: 'delete_record', config: { objectName: 'lead', filter: { stage: 'stale' }, multi: true } }
+  ```
+
+  - **Absent or `false`** — unchanged behaviour. The executor forwards
+    `multi: false`, so the write must name one row by scalar `id`; anything else
+    (a predicate, or `id: { $in: [...] }`) is refused by the engine with
+    `Delete requires an ID or options.multi=true`. **That refusal is the
+    contract**, not a defect to route around: it is what keeps an undeclared
+    unbounded write from happening by accident.
+  - **`true`** — the executor forwards `options.multi: true`, the write lands on
+    `driver.updateMany` / `deleteMany`, and the step's `acted` metric reports the
+    affected row count.
+
+  Additive and backward compatible: no existing flow changes behaviour, and every
+  by-id write keeps working untouched.
+
+  Two guards are unchanged and worth stating explicitly. The #3810
+  erased-condition guard still refuses a node whose authored filter condition
+  interpolated to nothing, `multi` or not — bulk intent says "many rows are
+  fine", never "a condition may vanish". And `multi: true` with **no** `filter`
+  is the whole object, by declaration: write the constraint you mean.
+
+  Wrong spellings are answered by name rather than by edit distance (which
+  reaches `multi` from none of them): `bulk` / `all` / `multiple` get the
+  prescription, and `options: { multi: true }` is called out as the engine's
+  options bag written at the node's altitude.
+
+- f0d98e1: fix(automation): a `wait` timer's wake-up job is dropped when the run leaves the node, not only when the timer fires (#5512)
+
+  A timer `wait` arms a one-shot job on entry (`flow-wait:<runId>:<nodeId>`,
+  `{ type: 'once', at }`) and, until now, only that job's own callback ever tore it
+  down. Every other way out of the pause left it armed:
+
+  - resumed early through the REST resume endpoint (`POST
+/api/v1/automation/:name/runs/:runId/resume` — a door the #3801 resume gate
+    deliberately leaves open for `screen`/`wait` pauses) or the SDK equivalent;
+  - cancelled while parked (`cancelRun`, ADR-0044);
+  - terminally failed under a subflow ancestor.
+
+  Reported from 17.0-rc2 acceptance: a `wait P1D` pause resumed early ran to
+  completion while its one-shot stayed `active: true` in `sys_job` with tomorrow's
+  deadline. For the next 24h anyone reading `sys_job` saw "a run is still waiting
+  to be woken" — the row contradicted the run — and when the deadline arrived the
+  job fired a resume at a run that had completed the day before (harmless: the
+  engine reports a machine-state error and the callback discards it, then the job
+  self-cancels). A long-running org accumulated one stale row per early wake-up.
+
+  **What changed.** The engine now tells the node its pause is over. `NodeExecutor`
+  gains an optional `onSuspensionReleased(release)` — the mirror of `suspend: true`
+  — called from the single choke point every consumption of a suspension already
+  passes through, with the `runId`, the node, the `correlation` the node minted at
+  suspend time, and why the pause ended (`resumed` / `cancelled` / `failed`). The
+  `wait` node implements it by cancelling the one-shot whose name it recognises as
+  its own, so the `sys_job` row goes inactive the moment the run leaves the node,
+  whichever route it left by. `SuspensionRelease` / `SuspensionReleaseReason` are
+  exported for plugin nodes that arm something on entry (a lease, a reminder, a
+  timeout) and need the same teardown.
+
+  Teardown is best-effort and runs after the suspension is consumed: a job service
+  that is down or throwing can neither delay nor fail the continuation — the engine
+  logs one warning naming the correlation an operator would cancel by hand. Node
+  types that arm nothing are unaffected (the hook is optional), and a pause that
+  armed no job — a signal wait, or a timer with no parseable duration — cancels
+  nothing, since its correlation is not a job name. Deprecated ADR-0018 node
+  aliases delegate the hook to their canonical executor, so authoring the old type
+  name cannot silently lose the teardown.
+
+  The timer callback keeps its own `finally` cancel: the two answer different
+  questions — "the run left the node" versus "this one-shot has had its single
+  shot", including shots that did not consume a pause. `cancel` is idempotent.
+
+### Patch Changes
+
+- 02a8256: fix(service-automation): connector 降级路径的两条日志改用结构化 `meta`,message 保持单行 (#5636)
+
+  ## 接缝
+
+  `degradeConnectorInstance`(#3017 的降级/重试路径)有两条记录报告的是**外来**失败,却把
+  它插进了日志 message —— 与 #5048(flow 绑定)、#5575(`reconcileDeclaredConnectors` 的
+  `fail()`)同一类,是那两单范围之外的第三个接缝:
+
+  - **husk 注册失败**(`warn`):`err` 来自 `engine.registerDegradedConnector` →
+    `ConnectorSchema.parse`,catch 自己的注释就写着「the entry's def no longer parses」,
+    也就是说这里预期接到的正是 `ZodError` —— 它的 `.message` 是 issue 数组的多行 JSON
+    dump,第一行只有一个 `[`。
+  - **降级公告**(`error`):文本是 `ConnectorUpstreamUnavailableError.message`,由第三方
+    provider factory 构造(ADR-0097 明确鼓励第三方去写)。spec 只定义错误类、不约束文本,
+    所以上游 SDK 的多行失败会原样落在这里。
+
+  ## 危害:这条 `warn` 的下游与 #5575 的 `error` 不同(实测)
+
+  `ObjectLogger` 把 `warn` 送 stdout、`error`/`fatal` 送 stderr,而 `serve` 的启动静默窗口
+  只包了 `process.stdout.write`。#5575 的接缝全是 `error`,所以那一单的结论是「启动缓冲根本
+  看不到」;这一条不同,而且差别是**测出来**的,不是推的:
+
+  - 它是 `warn` → stdout,缓冲**确实**看得到;
+  - 它在**冷启动**就会跑 —— `materializeDeclaredConnectors(ctx, { fatal: true })` 遇到上游
+    不可达是降级、不是抛错 —— 而窗口此时正开着(`serve` 在 config 加载前接管 stdout,直到
+    banner 打印才恢复);
+  - `BootLogCapture.offer()` 只在 `classifyBootLogLine` 能在该物理行上找到 `<ts> <LEVEL>`
+    头时才保留它,所以插值 dump 的每一条续行是被**直接丢弃**,不只是难解析。
+
+  对一份 13 行的插值 ZodError 实测:写出 13 行物理行,缓冲保留 **1** 行(那条止于 Zod `[`
+  的头行)、丢弃 **12** 行 —— 唯一被留下的那行不含任何事实。这正是 cloud#971 的原始形态。
+  `error` 那一条走 stderr,不经缓冲,危害是 #5575 那一串按行消费者(文件 sink、
+  `docker logs`/journald 送采集、`grep ERROR`):一条诊断散成 N 个无法归属的碎片。
+
+  ## 改法
+
+  两条都复用同包 `thrown-cause-diagnostics.ts` 的 `describeThrownForLog`(#5572/#5575 落地):
+  message 是不含换行的自足句子,cause 走 logger 的结构化 meta。位置按 `Logger` 契约区分,
+  并且是核对源码后确认的而非照抄:`warn(message, meta?)` 没有 `Error` 位,cause 就在**第二**
+  参;`error(message, error?, meta?)` 的 cause 在**第三**参(第二参塞原始 error 会让每次重试
+  的记录都附带完整堆栈)。
+
+  ## 刻意没有改的一件事
+
+  `degradedReason` —— `GET /connectors` 展示的、以及 `connector_action` 被拒时引用的那段文本
+  —— 仍然逐字保留 provider 自己的 message,包含换行。它是人透过 JSON 读的字段,不经按行切分
+  的消费者;重塑它属于另一次契约变更。因此调用点同时传 `reason`(那段文本)与 `cause`(抛出值
+  本身):前者喂 husk 与重试簿记,后者只喂日志记录。测试双向钉住了这个分离。
+
+- b746aa0: fix(service-automation): connector 物化失败的软路径改用结构化 `meta`;顺带修好 `ObjectLogger.error` 丢弃契约第三参的缺陷 (#5575)
+
+  ## service-automation:`fail(msg, cause)`
+
+  `reconcileDeclaredConnectors` 的报错器有两条路径(ADR-0097):冷启动 `throw`(fatal),
+  `metadata:reloaded` 之后 —— Studio publish、`os dev` 重编译 —— 记日志并让旧 connector
+  继续服务(soft)。其中两个调用点把**外来**的 `err.message` 插进那条日志 message:
+  `resolveInstanceAuth` 失败处,以及 provider factory 抛错处。这两个 message 都不是我们
+  自己的:credential resolver 由宿主提供
+  (`AutomationServicePluginOptions.credentialResolver`),provider factory 更是 ADR-0097
+  明确鼓励第三方去写的代码 —— 第一个用严格 Zod schema 校验 `providerConfig` 的 factory
+  抛出的就是 `ZodError`,它的 `.message` 是 issue 数组的多行 JSON dump,第一行是一个 `[`。
+
+  `ObjectLogger` 每次调用只写一条 `<ts> <LEVEL> <msg>` 记录,带换行的 message 会溢出到
+  不带等级头的后续物理行,于是运行时 stderr 的每一个按行工作的消费者 —— 文件 sink、
+  `docker logs`/journald 送进日志采集、一次 `grep ERROR` —— 都会把那些续行读成无法归属的
+  垃圾记录:一条诊断散成 N 个碎片。与 #5048 在 flow 绑定接缝上是同一类,也是同一条 #4632
+  原则:被搅烂的诊断比没有诊断更贵。
+
+  改法与 PR #5572 同源:`fail(msg, cause?)` —— message 是不含换行的自足句子,cause 按路径
+  分别渲染。soft 路径把 cause 交给 logger 的**结构化 meta**(`issues[]` / `error`);fatal
+  路径把 cause 文本接在抛出的 message 后面(`… cause: <text>`),因为 throw 不是日志记录,
+  内核失败通道原样打印,多行 ZodError dump 在终端里本来就好读 —— 同一个 cause,两种受众,
+  刻意不共用一种形状。`#5048` 引入的内部模块随之从 `flow-bind-diagnostics.ts` 更名为
+  `thrown-cause-diagnostics.ts`(`describeThrownForLog`),因为它从来不是 flow 专属的:
+  主题是日志管线,不是 metadata 类型。被拒键名仍放在 `unrecognized` 而不是 Zod 原本的
+  `keys`(`ObjectLogger` 的脱敏表按子串匹配,`keys` 含 `key`)。
+
+  **一处订正**:#5575 的 issue 正文把此处的危害归给了 `serve` 的启动诊断缓冲
+  (`BootLogCapture`)。那个缓冲看不到这条路径 —— `ObjectLogger` 把 `warn` 送 stdout(启动
+  静默窗口只包了 `process.stdout.write`),`error`/`fatal` 送 **stderr**,而且 soft 路径在
+  `metadata:reloaded` 之后才跑,窗口早已恢复。危害是上面那串按行消费者,以及日志查询根本
+  无法按字段过滤;机制写进了模块文档,连同 `warn`/`error` 下游不同这件事本身。
+
+  ## core:`ObjectLogger.error`/`fatal` 兑现契约声明的 `meta`
+
+  `Logger` 契约声明 `error(message, error?: Error, meta?)`。`ObjectLogger` 按形状分派,
+  所以 meta 也允许出现在 `error` 位 —— 这份宽容没问题;**丢掉一个自己声明的参数**有问题:
+  `error === undefined` 时旧代码走 `write(level, message, errorOrMeta)`,第三个参数从未被
+  读取。于是每一个按契约书写的 `logger.error(msg, undefined, { … })` 都只输出一条裸 message,
+  事实全部静默消失 —— `metadata`、`metadata-protocol`、`client`、`core/security` 里约 15 处
+  调用点今天就是这样(其中 `metadata/src/endpoint-matcher.ts` 送的正是一个 Zod issue 数组)。
+  契约的另外两个实现(`@objectstack/observability` 的 `ConsoleLogger`/`JsonLogger`)都老老实实
+  用了这个位置,所以是契约对、这一个实现错:declared ≠ enforced。
+
+  三种形状现在都被兑现,两个位置同时带值时以更靠后的 `meta` 为准。这一处修好之后,上述
+  调用点的诊断自动恢复(`client` 的 `HTTP request failed` 记录重新带上
+  `{method, url, status, error}`)。connector 接缝改用契约的第三参而非第二参,是刻意的:
+  把原始 error 塞进第二位会让每条记录都附带完整堆栈,ZodError 还会附带整段多行 dump ——
+  正是我们要消灭的无界形状。
+
+- f205c32: fix(service-automation): 降级注册那条 warn 不再插值 provider 的 reason,cause 走结构化 meta (#5660)
+
+  ## 接缝
+
+  `AutomationEngine.registerDegradedConnector` 自己那条记录:
+
+  ```ts
+  this.logger.warn(
+    `Connector registered DEGRADED: ${parsed.name} (origin: ${origin}) — ${reason}`
+  );
+  ```
+
+  `reason` 不是我们的文本 —— 唯一调用点(`plugin.ts` 的 `degradeConnectorInstance`)传进来的是
+  `ConnectorUpstreamUnavailableError.message`,由**第三方 provider factory** 构造(ADR-0097 明确
+  邀请第三方去写;spec 只约束 `code`,不约束文本),所以上游 SDK 的多行失败会原样落进 message。
+  `ObjectLogger.write()` 每次调用只打一个 `<ts> <LEVEL>` 头,带换行的 message 就变成若干物理行,
+  只有第一行是记录。
+
+  这是 #5048(flow 绑定)、#5575(`reconcileDeclaredConnectors` 的 `fail()`)、#5636
+  (`degradeConnectorInstance` 的两条)之后同族的**第四条**,在另一个文件、另一个方法、另一份
+  契约里,所以是单独一单。它值得单独修的理由是**顺序**,不是严重度:
+
+  - 它**先**发生 —— `degradeConnectorInstance` 先调 `engine.registerDegradedConnector(…)`,
+    之后才打自己那两条;
+  - 它在**默认分支**上 —— #5636 那条 `warn` 在 `catch` 里(husk 自己 parse 失败才走到),
+    这条在同一个 `try` **成功**时打,也就是每个实例首次降级都打。
+
+  即:#5636 落地之后,常见的冷启动降级路径上仍然留着一条会溢出的 warn。
+
+  ## 危害(与 #5636 同一条下游,机制已实测)
+
+  `ObjectLogger` 把 `warn` 送 stdout;`serve` 的启动静默窗口只包了 `process.stdout.write`;
+  冷启动会走到这个接缝 —— `materializeDeclaredConnectors(ctx, { fatal: true })` 遇到上游不可达是
+  **降级**、不是抛错 —— 而窗口此时正开着。`BootLogCapture.offer()` 只在 `classifyBootLogLine`
+  能在物理行上找到级别头时才保留该行,所以插值 message 的每条续行是被**直接丢弃**的。
+
+  本单新测试按 `pretty`(CLI 实际用的格式)实测了旧形状的代价,并且刻意报告了一个**比 #5636 更窄**
+  的结论:#5636 的载荷是 `ZodError.message`(首行只有一个 `[`),唯一被留下的那行不含任何事实;
+  这里的载荷是 provider 的散文,**首行会活下来**,丢掉的是它后面的 `cause:` / `hint:` 两行 ——
+  也就是「连哪个地址被拒」和「该去查什么」。3 行进,1 行留,2 行丢。
+
+  ## 改法(#5660 分诊 A 路)
+
+  `registerDegradedConnector` 签名末尾加可选 `cause?: unknown`(在有默认值的 `origin` 之后,
+  所以既有调用形状全部照旧编译 —— 新测试里就有一个两参调用在钉这件事)。message 变成单行自足
+  (name / origin / 这个状态的后果与后续动作),事实走 `warn(message, meta?)` 的第二参:
+
+  - `degradedReason` —— **恒定存在**,是这次注册**存进** husk 的那段文本。字段名照 #5573 挑过:
+    `ObjectLogger` 按 `password`/`token`/`secret`/`key` 子串递归脱敏,这个名字一个都不含;
+  - 抛出值自身的渲染(`error` 或 `issues`,经同包 `describeThrownForLog`)—— 仅当调用点传了
+    `cause` 时出现。它描述的是**失败**,`degradedReason` 描述的是**注册**;今天唯一的调用点从
+    前者派生后者所以两者重合,但记录形状不依赖这个巧合,将来传摘要的调用点也不会静默丢信息。
+
+  唯一调用点顺手把 `info.cause` 传了进来(该字段 #5636 已经存在)。
+
+  ## 刻意没做的两件事
+
+  - **`reason` / `degradedReason` 一字不动**。`GET /connectors` 展示的、`connector_action` 被拒时
+    引用的那段文本仍逐字保留 provider 自己的 message,换行包含在内 —— 它是人透过 JSON 读的,不经
+    按行切分的消费者(#5636 在上一层做了同样的判断)。测试从两个方向钉住了这个分离。
+  - **没有扩 `describeThrownForLog`**。`ConnectorUpstreamUnavailableError` 自带一个 `cause`
+    (底层 connect 错误),把**抛出值本身**一路带过来才使渲染它成为可能;但该 helper 目前只读
+    `.message` / `.issues`,所以嵌套 cause 今天还不会出现在记录里。这一点被一条测试如实钉住,
+    而不是含混带过 —— 扩宽它是改四个接缝共用的 helper,不是这个接缝该顺手做的决定。
+
+- cc5b048: 自动化引擎:嵌入式 host 从未调用 `sealNodeTypeVocabulary()` 时,首次执行 flow 会告警一次(#4792)
+
+  #4771 把 ADR-0018 的节点类型校验从 `registerFlow` 挪到了 `sealNodeTypeVocabulary()`。`AutomationServicePlugin` 在 `kernel:bootstrapped` 自动 seal,插件路径不受影响;但自己 `new AutomationEngine()` 且从不 seal 的嵌入式 host 就彻底拿不到这项校验,而且完全静默 —— 只有读过 changeset 的人才知道要补一行调用。现在这类 host 在第一次真正执行 flow 时会得到一条 `warn`,说明丢了什么、以及要调用哪个方法。
+
+  - 首次执行是最早既安全又必然到达的时点:正在跑 flow 的 host 显然已经装配完毕(否则这次执行本身就会 `NO_EXECUTOR` 失败)。
+  - **每个引擎实例一次**,不是每进程一次 —— 一个 host 建了多个引擎(按租户/环境各一个是常见形态)就是在每个上都漏了这次调用。
+  - 告警只报「缺了这次调用」这个关于 host 的事实,**不报**未知节点类型的审计结果:未 seal 的引擎其词汇表按契约仍可增长,在那里断言「某类型没有执行器」正是 #4771 删掉的那种会被本次启动反驳的判断。需要审计结果又不想封闭词汇表的 host 用只读的 `getUnknownNodeTypeAudit()`。
+  - 也**不会**顺带自动 seal:「谁决定词汇表封闭」只能有一个答案(host)。而且 seal 之后 `registerFlow` 会转为即时校验,自动 seal 会让「先执行、后注册插件执行器」(ADR-0018 允许)的嵌入式 host 开始收到 #4771 那种误报。
+
+  走 `AutomationServicePlugin` 的部署与已显式调用过 `sealNodeTypeVocabulary()` 的 host 都不会多打任何日志(两条哨兵测试守着)。
+
+- 8108787: fix(service-automation): flow 绑定失败的告警改用结构化 `meta`,不再把 Zod issue 数组塞进单行日志 (#5048)
+
+  `AutomationServicePlugin` 的五个 flow 绑定/读取失败点都把 `err.message` 插进一条
+  单行 `logger.warn`。而 `registerFlow` 用 `FlowSchema` 解析,#4001 关闭 metadata
+  schema 之后未知键是**抛出**而不是被丢弃 —— ZodError 的 `.message` 是 issue 数组的
+  多行 JSON dump,第一行就是一个 `[`。
+
+  两级管线随后把余下内容销毁:`ObjectLogger.write()` 每次调用只写一条
+  `<ts> <LEVEL> <msg>` 记录,带换行的 message 会溢出到没有等级前缀的后续行;而
+  `serve` 的启动诊断缓冲(`BootLogCapture.offer()`)只保留 `classifyBootLogLine`
+  能认出等级前缀的行。于是一次启动里 24 个绑不上的 flow,给出的是 24 条点了名字、
+  然后说一个 `[` 的告警 —— cloud#971 能横跨整条 rc.1 发布线没人发现,就是因为这个。
+
+  现在这些位置改为:message 是不含换行的静态字符串,事实交给 logger 的 `meta`
+  第二参(仓库里每个 `Logger` 实现都用 `JSON.stringify` 序列化它,值里的换行变成
+  `\n` 转义,整条记录稳定占一行,正是启动缓冲会保留的形态)。新增内部模块
+  `flow-bind-diagnostics.ts` 把 Zod issue 摊平成 `{ code, path, message,
+unrecognized }`:`path` 渲染成 `nodes[0].config.x`,被拒的键名放在
+  `unrecognized` 而不是 Zod 原本的 `keys` —— 因为 `ObjectLogger` 的默认脱敏表
+  (`['password','token','secret','key']`)按**子串**递归匹配,`keys` 含 `key`,
+  原样转发 `err.issues` 会渲染成 `"keys":"***REDACTED***"`,恰好丢掉读者唯一需要
+  的那个事实。issue 列表有上限,超出时用 `issueCount` **显式声明**总数,而不是静默
+  截断。非 ZodError 的失败退回 `error` 字符串分支。
+
+  无公开 API 变化;日志文本的可 grep 前缀(`cold-boot flow bind: failed to
+register`、`flow re-sync: failed to register`、`flow pull from ObjectQL
+registry failed`、`flow read from protocol failed`)全部保留。与 #4632 同源:
+  被截断的诊断比没有诊断更贵。
+
+- c5adfe1: fix: 节点执行与热重载 shutdown 的超时守卫在 race 落定时被清除,不再留下孤儿定时器 (#4952)
+
+  #4813(PR #4874,内核 init/start)与 #4875(PR #4950,周期性健康检查)修掉的是同一种漏法:
+  守卫 armed 之后就被扔掉 —— 被守护的一方赢下 race 之后,那根 `setTimeout` 既没 `clearTimeout`
+  也没 `unref()`,带着 ref 一直把事件循环钉满整个超时预算。本次清仓剩下的两处生产实例:
+
+  - **`AutomationEngine.executeWithTimeout()`**(`service-automation`)—— 三处里量级最大的一处:
+    **每个声明了 `timeoutMs` 的流程节点各一根**,孤儿数随流程节点数 × 触发频率线性增长;一次性进程
+    (`os` CLI 跑到 flow 的路径)干完活之后还会被最长的那根守卫按住到超时才退出。
+  - **`HotReloadManager.reloadPlugin()`**(`core`)—— 插件 `destroy()` 的 shutdown 守卫,与 #4813
+    修掉的两处一字不差:一次毫秒级完成的热重载,照样把循环钉满 `shutdownTimeout`。
+
+  两处修法与 #4874 / #4950 同形,不新造变体:私有 helper +
+  `try { return await Promise.race([...]) } finally { clearTimeout(guard) }`。`hot-reload.ts` 的
+  helper 把入参放宽到 `T | PromiseLike<T>`(Plugin 契约允许同步 `destroy()`);`engine.ts` 的不放宽
+  (`NodeExecutor.execute` 声明返回 `Promise`)。
+
+  **为什么是 `clearTimeout` 而不是 `unref()`。** `unref()` 让定时器不再钉住事件循环的同时,也让它
+  不再是一个守卫 —— 若被守护的一方永不 settle 且没有别的东西撑着事件循环,Node 会在定时器触发之前
+  退出,超时被静默吞掉。守卫必须在 race 未决期间保持 ref'd、在落定那一刻被回收,这正是
+  `finally { clearTimeout(guard) }` 表达的语义。两处的回归测试各自沿用 #4950 的双向写法:
+  真实定时器下不留 ref'd 定时器、fake timers 下连跑多轮不累积(计数能看见 `unref()` 过的定时器,
+  因此识破 `unref()` 式的假修复)、以及被守护方真的挂住时超时照常上报。
+
+  超时时长(`timeoutMs` / `shutdownTimeout`)一个都没动 —— 问题从来不在时长,而在没人回收。
+
+- dadf542: fix(service-automation): 启动路径三条日志改用结构化 `meta`,message 保持单行 (#5661)
+
+  ## 接缝
+
+  `AutomationServicePlugin` 里还有三处把**外来**错误的文本插进日志 message —— 与
+  #5048(flow 绑定)、#5575(`reconcileDeclaredConnectors` 的 `fail()`)、#5636
+  (`degradeConnectorInstance`)同一类,是那三单范围之外的第四组:
+
+  - **`registerRunObject`**(`warn`):`err` 来自内核服务注册表(`ctx.getService('manifest')`
+    或 `manifest.register()` 的解析拒绝),文本不是我们的。
+  - **启动 probe**(`error`):`err` 来自 `candidate.probe()`,即**数据源驱动**抛出的错误。
+  - **重启后 wait-timer 重新挂载**(`error`):`err` 是从 `rearmSuspendedWaitTimers` 逃出来
+    的任何东西。
+
+  ## 为什么后两条尤其值得改
+
+  它们的**存在理由**就是可读性。代码自己写明后果 —— 「suspended runs will NOT survive a
+  restart」「every wait/approval paused before this restart will hang indefinitely」—— 并被
+  #4632 特意定为 `error` 级,好让运维能找到。而 `ObjectLogger.write()` 一次调用只加一个
+  「时间戳 + 级别」记录头,所以带换行的 message 会变成多个物理行、只有第一行有头:文件 sink
+  把其余行当成独立记录存,采集端读成无法归属的碎片,`grep ERROR` 只捞到那条不含任何事实的
+  头行。这个 plugin 里最响的耐久性告警,恰好是最可能以读不懂的形态抵达的那一条。
+
+  第一条的危害是另一种,并且是测出来的:`warn` 走 **stdout**,正是 `serve` 启动静默窗口包住
+  的那条流,而 `BootLogCapture.offer()` 只在该物理行上找得到级别头时才保留它 —— 所以续行是
+  被**直接丢弃**,不只是难解析。`registerRunObject` 在 `init()` 里跑,正处于窗口开着的时候。
+
+  ## 改法(零新词汇)
+
+  三处都复用同包 `thrown-cause-diagnostics.ts` 的 `describeThrownForLog`:message 是不含换行
+  的自足句子,cause 走 logger 的结构化 meta。参数位按 `Logger` 契约区分 ——
+  `warn(message, meta?)` 没有 `Error` 位,cause 在**第二**参;`error(message, error?, meta?)`
+  的 cause 在**第三**参(第二参塞原始 error 会让记录额外附带堆栈)。#4632 要求的「后果 + 修
+  法」仍然完整留在 message 的第一行里,只是末尾的 `: ${err.message}` / `Cause: ${err.message}`
+  换成了指向 meta 的一句话。
+
+  `pnpm check:durability-log-level` 仍绿:24 个耐久性接缝,三处 `error` 未降级、未改成 rethrow。
+
+  ## 测试
+
+  新增 `plugin-startup-log-cause.test.ts`:13 个用例全部让真 `ObjectLogger` 写真字节再读回来
+  (照 #5662 的先例 —— spy 只能证明接缝**调用**了什么,证明不了按行消费者会**看到**什么,而
+  后者才是 cloud#971 付掉一整条 rc 线的那一半)。三条接缝各自钉住「多行 cause 不进 message、
+  进结构化 meta」、参数位、以及无 cause 时输出零字节;末尾两个用例把插值形态与结构化形态并排
+  渲染、量出差别(`warn` 侧:一次调用多个物理行、启动缓冲只留下止于 Zod `[` 的那一行;`error`
+  侧:一条记录散成三个碎片,后两行无记录头)。
+
+  `plugin-suspended-run-wiring.test.ts` 里那条 #4420 的 probe 用例做了重新裁决而不是重新拼写:
+  它原来断言驱动文本出现在 message 里,现在双向断言 —— message 里**没有**、meta 里**有**。
+  单向的断言在 cause 被整个丢掉时也会通过。
+
+- c42a19a: fix(service-automation): `wait` 节点的五条日志不再把外来 cause 拼进 message,改走 meta (#5737)
+
+  `builtin/wait-node.ts` 里有五处记录把**我们不控制文本**的失败原因(数据源驱动、
+  job 服务、`engine.resume()` 的错误信封)直接插进日志 message。`ObjectLogger.write()`
+  一次调用只加一个「时间戳 + 级别」记录头,所以 message 里的换行会把**一条**记录变成
+  多个物理行,后面几行既无级别也无时间戳。在 `pretty` / `text` 格式(`os dev` / `os serve`
+  的默认)下,文件 sink 会把它们当成独立记录存,日志采集器读成无主碎片,而
+  `grep ERROR` 只捞得到不含任何事实的那一行 —— 恰恰是运维正在找的那条。
+
+  五处现在都改成:**message 单行自足**,外来 cause 交给 logger 的结构化参数位 ——
+  按 `Logger` 契约(`packages/spec/src/contracts/logger.ts`)选位置,`warn(message, meta?)`
+  用第二参,`error(message, error?, meta?)` 用**第三**参(第二参留空,否则每条记录都
+  会带上整个栈)。与 #5048 / #5575 / #5636 / #5661 完全同一套修法,零新词汇。
+
+  对运维可见的变化(日志形状,非行为):
+
+  - 这五条记录各自恒为**一个**物理行,不论日志格式;
+  - 原因文本从 `msg` 末尾的 `Cause: …` 移到记录的 `error` 字段(`meta`),多行驱动错误
+    由 `JSON.stringify` 转义换行后完整保留 —— 一个字节都不丢;
+  - 消息里原本指向拼接文本的「the cause below」措辞改为指向记录的 meta;
+  - 级别一律不变。其中三处是 #4632 明确定为 `error` 的耐久性诊断
+    (`rearmSuspendedWaitTimers` 的 store 不可列、overdue 运行叫不醒、唤醒 job 没排上),
+    仍是 `error`,`pnpm check:durability-log-level` 照旧覆盖;「无 job 服务」那条声明式
+    缺失仍是 `warn`。
+
+  按 `Cause:` 字面量 grep 这五条记录的日志查询需要改成读记录的 `error` 字段。
+
+- 229d29e: fix(automation): a wait node's timer wake-up no longer disarms itself when the store outage means it never woke the run (#5529)
+
+  A timer `wait` arms one job to wake its run. That job used to disarm itself in an
+  unconditional `finally` — and `AutomationEngine.resume()` reports failure by
+  **returning** a code rather than throwing, so "this shot consumed the pause" and
+  "this shot missed" were indistinguishable to that `finally`. Both were cancelled.
+
+  On `STORE_UNAVAILABLE` that was a durability hole. The durable suspended-run
+  store being unreadable does **not** mean the run is gone (#4420 draws exactly
+  that line): the pause was never consumed, the run is still parked at its wait
+  node, and its row is still there — but the one job that was ever going to wake it
+  had just retired itself. Nothing then woke that run until the next process start,
+  where `rearmSuspendedWaitTimers` picks it up as overdue. A store that wobbled for
+  the one moment the deadline landed, plus no restart, meant a run parked forever.
+
+  The one-shot now settles on the resume's return code:
+
+  - **`STORE_UNAVAILABLE`** — the job stays armed, and the degradation is reported
+    at `error` (this path was previously silent — the result was discarded without
+    even a `warn`). The line names the job, the run, and both remedies.
+  - **everything else** — cancelled exactly as before: success consumed the pause,
+    `RESUME_IN_PROGRESS` means a concurrent resume is consuming it, a machine-state
+    failure means there is no pause left to serve, and a thrown error is not a
+    store outage.
+
+  Keeping the job armed is **not** self-healing, and the log line says so rather
+  than implying a retry: a `once` schedule is a single `setTimeout`, so it never
+  re-fires on its own. What survival buys is the two things `cancel` destroys — the
+  `sys_job` row stays `active` with its deadline (true, here: the run really is
+  still waiting) instead of flipping to `active: false` and reading as "this
+  wake-up is done", and the registration stays in the job service, so
+  `trigger('flow-wait:<runId>:<nodeId>')` re-fires that wake-up once the store is
+  back **without a restart**. After a cancel, `trigger` reports the job as not
+  found and a restart is the only path left.
+
+  Both sites that arm this job — the wait node's own arming path and the cold-boot
+  re-arm — now share one handler, so they cannot drift, the same reason the job's
+  name is a single declaration. This is separate from the `onSuspensionReleased`
+  teardown added in #5512 and does not replace it: that one fires when the **run**
+  leaves the node, this one when the **job** has had its single shot.
+
+  No authoring surface changes; no flow needs editing.
+
+- b508244: automation: a pausing node type that never declares `resumeAuthority` is now named
+  at registration, and the four pausing built-ins declare theirs (#5561)
+
+  `registerNodeExecutor` warns once per node type (per engine instance) when a
+  descriptor declares `supportsPause: true` and omits `resumeAuthority` — the state in
+  which the #3801 resume gate silently treats every pause that type creates as
+  raw-resumable through the generic resume route. The line names the two legal values
+  and says that declaring `'any'` explicitly silences it and changes no behaviour, so
+  a node whose pause really is open to the route is not pushed toward `'service'` to
+  quieten a log.
+
+  `screen`, `wait`, `subflow` and `map` now declare `resumeAuthority: 'any'`
+  explicitly. Each was already correct on its own terms — it was inheriting the value
+  rather than stating it — so the warning names nothing on a stock boot today and only
+  catches future omissions. Authority resolution is unchanged: `resolveResumeAuthority`
+  still resolves an absent value to `'any'`.
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [b746aa0]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [0f17114]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [58f3220]
+- Updated dependencies [07f1822]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [d9971d3]
+- Updated dependencies [eb3e650]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [46365ab]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [c5adfe1]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [bf1edef]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/core@17.0.0-rc.4
+  - @objectstack/formula@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Minor Changes
diff --git a/packages/services/service-automation/package.json b/packages/services/service-automation/package.json
index 5046e00bf6..0e820cd394 100644
--- a/packages/services/service-automation/package.json
+++ b/packages/services/service-automation/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/service-automation",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "Automation Service for ObjectStack — implements IAutomationService with plugin-based DAG flow execution engine",
   "type": "module",
diff --git a/packages/services/service-cache/CHANGELOG.md b/packages/services/service-cache/CHANGELOG.md
index 7f31877e8c..0b871307d8 100644
--- a/packages/services/service-cache/CHANGELOG.md
+++ b/packages/services/service-cache/CHANGELOG.md
@@ -1,5 +1,135 @@
 # @objectstack/service-cache
 
+## 17.0.0-rc.4
+
+### Patch Changes
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [b746aa0]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [d9971d3]
+- Updated dependencies [eb3e650]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [46365ab]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [c5adfe1]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/core@17.0.0-rc.4
+  - @objectstack/observability@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Patch Changes
diff --git a/packages/services/service-cache/package.json b/packages/services/service-cache/package.json
index c78363fbeb..edcb850851 100644
--- a/packages/services/service-cache/package.json
+++ b/packages/services/service-cache/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/service-cache",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "Cache Service for ObjectStack — implements ICacheService with in-memory and Redis adapters",
   "type": "module",
diff --git a/packages/services/service-cluster-redis/CHANGELOG.md b/packages/services/service-cluster-redis/CHANGELOG.md
index 78c366514b..d811536fec 100644
--- a/packages/services/service-cluster-redis/CHANGELOG.md
+++ b/packages/services/service-cluster-redis/CHANGELOG.md
@@ -1,5 +1,127 @@
 # @objectstack/service-cluster-redis
 
+## 17.0.0-rc.4
+
+### Patch Changes
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [d9971d3]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/service-cluster@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Patch Changes
diff --git a/packages/services/service-cluster-redis/package.json b/packages/services/service-cluster-redis/package.json
index 37f0ed7d55..0ff95b8c24 100644
--- a/packages/services/service-cluster-redis/package.json
+++ b/packages/services/service-cluster-redis/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/service-cluster-redis",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "Redis cluster driver for ObjectStack — implements IPubSub/ILock/IKV/ICounter against Redis using ioredis.",
   "type": "module",
diff --git a/packages/services/service-cluster/CHANGELOG.md b/packages/services/service-cluster/CHANGELOG.md
index 3751343e70..bf5e82ff93 100644
--- a/packages/services/service-cluster/CHANGELOG.md
+++ b/packages/services/service-cluster/CHANGELOG.md
@@ -1,5 +1,134 @@
 # @objectstack/service-cluster
 
+## 17.0.0-rc.4
+
+### Patch Changes
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [b746aa0]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [d9971d3]
+- Updated dependencies [eb3e650]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [46365ab]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [c5adfe1]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/core@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Patch Changes
diff --git a/packages/services/service-cluster/package.json b/packages/services/service-cluster/package.json
index ec2ceeb975..03f417952d 100644
--- a/packages/services/service-cluster/package.json
+++ b/packages/services/service-cluster/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/service-cluster",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "Cluster Service for ObjectStack — pluggable PubSub/Lock/KV/Counter primitives. Memory driver included; postgres/redis drivers ship separately.",
   "type": "module",
diff --git a/packages/services/service-datasource/CHANGELOG.md b/packages/services/service-datasource/CHANGELOG.md
index 5b7d50d4d0..db8301e450 100644
--- a/packages/services/service-datasource/CHANGELOG.md
+++ b/packages/services/service-datasource/CHANGELOG.md
@@ -1,5 +1,241 @@
 # @objectstack/service-external-datasource
 
+## 17.0.0-rc.4
+
+### Minor Changes
+
+- 99d7a93: fix(service-datasource): a `pool` block on a sqlite datasource is rejected, not dropped in silence (#5714)
+
+  `datasource.pool` is declared, strict and documented, and until now it reached a
+  driver only from the arms that build a pooled client: `postgres` / `mysql` hand
+  `buildSqlPool(spec)` to `SqlDriver`, `mongo` maps `min`/`max` onto the client's
+  `minPoolSize`/`maxPoolSize`. The `sqlite` and `sqlite-wasm` arms passed no pool
+  at all — `resolveSqliteDriver` has no such option and `SqliteWasmDriver` does
+  not take one — so an author who sized their pool got the driver's own single
+  connection and nothing said otherwise. Measured through the real factory:
+
+  ```text
+  sqlite   + pool{min:3,max:9}   knex.client.config.pool {"createTimeoutMillis":15000}   live {min:1,max:1}
+  postgres + pool{min:3,max:9}   knex config.pool {"min":3,"max":9}                      live {min:3,max:9}
+  ```
+
+  `examples/app-crm` was the live specimen: `CrmDatasource` asked for
+  `{ min: 1, max: 5 }` and ran on one connection.
+
+  **Wiring it through would be wrong, not merely more work.** Knex's
+  better-sqlite3 dialect pins `{min:1,max:1}` on purpose: every pool acquire runs
+  `new Database(filename)`, so two connections to `:memory:` are two separate,
+  mutually invisible databases. Honouring `max: 5` there would split one
+  datasource's data across five stores. Sizing a SQLite pool is not a knob the
+  platform can offer, so the declaration is rejected at authoring/publish instead
+  — Prime Directive #12: fix the metadata at the producer, reject it loudly, never
+  tolerate it in the consumer.
+
+  **Observable behaviour change — read this if any datasource declares `pool`.**
+  A `sqlite` / `sqlite-wasm` datasource carrying a `pool` block now **fails**
+  where it used to boot with the block ignored:
+
+  - **Boot** (`DatasourceConnectionService.connectDeclared`) refuses before a
+    single connection is attempted, naming every offending datasource in one
+    throw. Every _declared, active_ datasource is judged, including the ones the
+    ADR-0062 D2 gate leaves unconnected — a pool block on a datasource nobody
+    connects is exactly as dropped as a connected one's. `active: false` is
+    skipped, so switching a datasource off remains the way out.
+  - **Setup → Datasources** (`createDatasource` / `updateDatasource`) rejects the
+    draft before the record is stored. An update that touches neither `pool` nor
+    `driver` is not re-judged, so a record written before this gate stays editable
+    — including the `active: false` that takes it out of service.
+  - **The driver factory** (`createDefaultDatasourceDriverFactory`) rejects it as
+    the last door, for hosts that build drivers directly.
+
+  The fix is to delete the block: `pool` is a no-op on SQLite either way, so
+  removing it changes nothing about how the datasource runs.
+
+  ```diff
+   export const CrmDatasource = defineDatasource({
+     name: 'crm_primary',
+     driver: 'sqlite',
+     config: { filename: ':memory:' },
+  -  pool: { min: 1, max: 5 },
+     active: true,
+   });
+  ```
+
+  `pool` is unchanged and still honoured on `postgres` / `mysql` / `mongo`, and a
+  plugin-contributed driver id (`com.vendor.snowflake`) is not judged at all —
+  the same boundary the `datasource.config` gate draws in #4410: the platform
+  validates what it can construct.
+
+  This verdict is an **authoring** error, not a connect failure: it never goes
+  through the ADR-0062 D5 degradation path, so `OS_ALLOW_DRIVER_CONNECT_FAILURE`
+  does not apply to it and is not suggested. That hatch exists for a database that
+  is unreachable — a fact about the world that may resolve itself. A `pool` the
+  driver cannot read is a fact about the metadata.
+
+  Hosts that inject their own driver factory can hold the same contract with the
+  newly exported `assertDatasourcePoolSupported` / `driverReadsDeclaredPool` /
+  `unsupportedPoolIssue` / `POOL_UNSUPPORTED_DRIVER_IDS`.
+
+### Patch Changes
+
+- cba7454: fix(service-datasource): give this package's vitest run a 60s `testTimeout` — close the #4856 coverage hole that let the merge queue evict unrelated PRs (#6044)
+
+  `packages/services/service-datasource` had no `vitest.config.ts` at all, so
+  every case ran under vitest's **5000ms** default. #4856 fixed this class of
+  flake by setting per-package timeouts in each package's own `vitest.config.ts`
+  — a structure that cannot reach a package with no config file to carry it.
+
+  The cases that build a REAL driver pay a one-time `@objectstack/driver-sql`
+  (knex) import inside the first case that reaches it. In
+  `datasource-pool-support.test.ts` the pool rejections throw before that import,
+  so "sqlite WITHOUT a pool still builds exactly as before" is the first case
+  through it: measured idle it runs ~1.1s while its neighbours run 0-2ms (the
+  postgres/mysql cases ride the module cache at 31/82ms). ~4.6x headroom against
+  5000ms holds on a PR branch and not on a merge-queue runner building several
+  PRs' batches at once — the observed signature: intermittent reds only in queue
+  full builds, evicting PRs that never touched this package (#5999 twice, #5973
+  once, 2026-08-06).
+
+  `testTimeout: 60_000` reuses #4856's value rather than inventing a new number,
+  set at the config layer so future cases are covered on arrival. Isolation was
+  reviewed rather than assumed (the #6044 triage forbade a timeout-only closure):
+  the flaky case builds `:memory:`, unprobed on the production path, never opens
+  a connection or loads the native addon, and every factory-door case destroys
+  its knex handle; the boot and wizard doors run on per-case fakes. No temp
+  files, no ports, no shared mutable state across cases — the red was load
+  variance on a real one-time import, not a leak.
+
+  No runtime, schema or public API change — test configuration only.
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [64cd010]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [b746aa0]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [08f93bc]
+- Updated dependencies [d9971d3]
+- Updated dependencies [eb3e650]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [02dc076]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [46365ab]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [c5adfe1]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/types@17.0.0-rc.4
+  - @objectstack/core@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Minor Changes
diff --git a/packages/services/service-datasource/package.json b/packages/services/service-datasource/package.json
index 3f989c45cc..d71dba0cd0 100644
--- a/packages/services/service-datasource/package.json
+++ b/packages/services/service-datasource/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/service-datasource",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "The datasource service (ADR-0015): external-table federation (introspect/draft/import/validate) + runtime UI datasource lifecycle (list/test/create/update/remove + REST routes). Open-source mechanism; the tier line falls on which ICryptoProvider / driver factory a host injects.",
   "type": "module",
diff --git a/packages/services/service-i18n/CHANGELOG.md b/packages/services/service-i18n/CHANGELOG.md
index 4b7095ab49..4e180194ce 100644
--- a/packages/services/service-i18n/CHANGELOG.md
+++ b/packages/services/service-i18n/CHANGELOG.md
@@ -1,5 +1,138 @@
 # @objectstack/service-i18n
 
+## 17.0.0-rc.4
+
+### Patch Changes
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [64cd010]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [b746aa0]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [08f93bc]
+- Updated dependencies [d9971d3]
+- Updated dependencies [eb3e650]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [02dc076]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [46365ab]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [c5adfe1]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/types@17.0.0-rc.4
+  - @objectstack/core@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Patch Changes
diff --git a/packages/services/service-i18n/package.json b/packages/services/service-i18n/package.json
index 16ee3afc79..6d0d8632ab 100644
--- a/packages/services/service-i18n/package.json
+++ b/packages/services/service-i18n/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/service-i18n",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "I18n Service for ObjectStack — implements II18nService with file-based locale loading",
   "type": "module",
diff --git a/packages/services/service-job/CHANGELOG.md b/packages/services/service-job/CHANGELOG.md
index 33bc0844ab..4984397ec8 100644
--- a/packages/services/service-job/CHANGELOG.md
+++ b/packages/services/service-job/CHANGELOG.md
@@ -1,5 +1,138 @@
 # @objectstack/service-job
 
+## 17.0.0-rc.4
+
+### Patch Changes
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [b746aa0]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [d9971d3]
+- Updated dependencies [eb3e650]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [e98fb14]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [1b9a53b]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [46365ab]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [c5adfe1]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [f104bab]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/core@17.0.0-rc.4
+  - @objectstack/platform-objects@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Patch Changes
diff --git a/packages/services/service-job/package.json b/packages/services/service-job/package.json
index e7b1afdb1f..5a47aab64b 100644
--- a/packages/services/service-job/package.json
+++ b/packages/services/service-job/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/service-job",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "Job Service for ObjectStack — implements IJobService with setInterval and cron scheduling",
   "type": "module",
diff --git a/packages/services/service-knowledge/CHANGELOG.md b/packages/services/service-knowledge/CHANGELOG.md
index d5a3ae7f01..fd638f1e79 100644
--- a/packages/services/service-knowledge/CHANGELOG.md
+++ b/packages/services/service-knowledge/CHANGELOG.md
@@ -1,5 +1,160 @@
 # @objectstack/service-knowledge
 
+## 17.0.0-rc.4
+
+### Patch Changes
+
+- 44106d9: 知识索引在保留期回收(reap)删除行之前先去索引,不再留下孤儿条目(#4672)。
+
+  `object` 知识源是**逐记录投影**,而 `LifecycleService` 的保留期回收按谓词删行 ——
+  ADR-0057 §3.3 又禁止把它扇出成 N 条逐记录事件(清理会回灌正在清空的表)。结果是行没了、
+  文档还在:孤儿条目仍会占掉 `topK` 名额(权限过滤发生在适配器返回之后),`isSystem`
+  调用方还会直接读到它们。
+
+  现在 `KnowledgeServicePlugin` 会为每个被 `object` 源投影的对象注册一个 ADR-0057
+  **reap guard**:sweep 在删除前把候选行交给 guard,guard 按 id 删除对应文档,只确认删除
+  成功的行。
+
+  - **失败方向**:`adapter.delete` 失败 ⇒ 该行本轮**保留**,下次 sweep 重试。允许「行比索引
+    条目活得久」,绝不允许反过来。
+  - **组合语义**:多个 guard 按交集组合(#5535),因此它既不会顶掉 `service-storage` 的字节
+    回收 guard,也不会被其顶掉。
+  - **分批**沿用 sweep 自身的约束(每批 500 行、每轮 20 批)。
+  - **退出开关**:源上的 `refresh.onRecordChange: false` 或插件的 `enableEventSync: false`
+    会同时关掉两个方向的内联同步(事件订阅与 reap 去索引)。
+
+  零新增契约面:未新增任何 spec 键、`IKnowledgeAdapter` 成员或 `packages/objectql` 改动 ——
+  经由既有的 `ctx.getService('lifecycle')` duck-type + `registerReapGuard` seam 接入,与
+  `service-storage` 回收 `sys_file` 字节的方式一致。
+
+  应用层谓词写(调用方自己的 `multi: true` 写)**仍不覆盖**,#4639 的 warn 保留并已改写为
+  准确描述这条分界。
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [b746aa0]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [d9971d3]
+- Updated dependencies [eb3e650]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [46365ab]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [c5adfe1]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/core@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Patch Changes
diff --git a/packages/services/service-knowledge/package.json b/packages/services/service-knowledge/package.json
index 5ff438dae3..1ab70bb9f9 100644
--- a/packages/services/service-knowledge/package.json
+++ b/packages/services/service-knowledge/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/service-knowledge",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "Knowledge Service for ObjectStack — orchestrator implementing IKnowledgeService over pluggable IKnowledgeAdapter backends (RAGFlow, LlamaIndex, Dify, in-memory).",
   "type": "module",
diff --git a/packages/services/service-messaging/CHANGELOG.md b/packages/services/service-messaging/CHANGELOG.md
index 78d5bf87cc..57e52005fd 100644
--- a/packages/services/service-messaging/CHANGELOG.md
+++ b/packages/services/service-messaging/CHANGELOG.md
@@ -1,5 +1,179 @@
 # @objectstack/service-messaging
 
+## 17.0.0-rc.4
+
+### Minor Changes
+
+- 9c90ea0: feat(sms): 短信全局日发送配额 —— 成本总量闸 (#2814)
+
+  #2780 给 OTP 端点落了**按号码**的防滥用（60s 冷却 + 每号码 5 条/小时）。那挡住的是「一个号码花多少钱」，挡不住「这套部署一天花多少钱」：攻击者轮换上万个不同号码时，每个号码都稳稳待在自己的预算里，而日累计账单没有任何上限——这正是 SMS pumping / toll fraud 的典型打法。更要紧的是，按号码那道闸住在 better-auth 的 `hooks.before` 里，只看得见 auth 端点：`notify(channels:['sms'])` 与邀请短信从旁边直接走过去，一条都不计数。
+
+  本次新增一道**总量**闸，扣减点放在所有出站短信本来就必经的那一处 —— `SmsService.send()`。OTP、邀请、messaging `sms` channel 三条路无论从哪扇门进来，都记在同一本账上。
+
+  ## 新增设置项
+
+  `sms` 命名空间新增 `daily_quota`（Daily send limit，number，默认 `0` = 不限）：这套部署每个 **UTC 自然日**允许发出的短信总条数。超出后拒发，直到 00:00 UTC。env 覆盖沿用既有的每键机制，无需额外接线：`OS_SMS_DAILY_QUOTA=2500`。
+
+  `0` 是出厂姿态，所以升级本身不改变任何现有部署的发送行为——闸门要由运营者显式配置才会闭合。
+
+  ## Observable behaviour change
+
+  **配置配额后，发送可能被拒**，两条路径的表现分别是：
+
+  - OTP / 邀请路径 —— `SendSmsResult.status='failed'`，`error` 为 `TOO_MANY_REQUESTS: daily SMS quota exhausted`。刻意与按号码闸抛出的 `TOO_MANY_REQUESTS` 用同一个码，且**不带任何剩余额度细节**：从外面看，两道墙必须长得一样，攻击者不该能试探出自己撞的是哪一道。
+    ⚠️ 但这个码**目前到不了 HTTP 调用方**：`AuthManager.deliverPhoneOtp` 把它重抛成普通 `Error`，而 better-call 对非 `APIError` 一律回 500（实测，见 #6039）。也就是说 OTP 端点上，按号码闸回 429、总量闸回 500。补齐要动 plugin-auth，已单独立案。
+  - messaging `sms` channel —— `SendResult.ok=false`，且 `classifyError` 返回 `'rate_limited'`（此前一律 `'retryable'`）。投递落进 outbox 走退避重试 / 死信，不会被静默丢弃；`rate_limited` 与 `retryable` 走同一条重试阶梯，但把「额度用尽」与「网关抖动」在投递记录上区分开。
+
+  ## 计数落在哪里
+
+  复用仓内唯一那份定窗计数（`incrementFixedWindow`）与它的惰性存储解析（`createLazyCounterStore`，#4772/#4790），不写第三份：
+
+  - 有 kernel `cache` 服务时计在共享 cache（集群共享与否取决于 cache 本身）；
+  - 解析不到时降级为有界的进程内计数，并由解析器**点名**打一条 warn，说明降级的代价（N 节点部署最多可花 N× 配额）；
+  - 解析在**计数被消费时**发生，而非插件 init —— 后注册的 cache 也能在下一次发送时被接上（#4772 的坑）。
+
+  窗口是 UTC 自然日，且由两个机制同时保证：计数键带 UTC 日期（`sms-daily-sends:2026-08-06`），窗口开启时的 TTL 恰为距下一个 UTC 午夜的秒数。任一机制单独也能翻窗，合起来则不可能互相矛盾。
+
+  ## 两条刻意的姿态
+
+  - **fail-open**：计数存储读不到时，闸门**放行**并打一次 warn。短信成本闸不能把登录拖下水（#2814 诉求 4）。
+  - **配额值的钳制在消费侧**：manifest 上的 `min: 0` 今天并不被 `validatePatch` 执行（#5932），所以负值 / `NaN` / `Infinity` / 非数字都会原样抵达读取方。这些一律降级为 `0`（不限）并**点名**打 warn，而不是拒发、也不是替运营者编一个别的默认值——一个设置表单里的手误不该变成手机登录的全站故障，而编一个没人声明过的上限只会把手误藏进看似合理的行为里。
+
+  ## 不在本次范围
+
+  诉求中的**每租户日配额**（`daily_quota_per_tenant`）未实现：`SendSmsInput`（`@objectstack/spec/contracts`）不携带任何租户标识，而在 service 侧另造一个只此一家的拼法就是 Prime Directive #12 明令禁止的影子契约。租户维度要么落在 spec 契约上，要么不落——详见 #2814 上的讨论。
+
+### Patch Changes
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [b746aa0]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [d9971d3]
+- Updated dependencies [eb3e650]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [e98fb14]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [1b9a53b]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [46365ab]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [c5adfe1]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [f104bab]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/core@17.0.0-rc.4
+  - @objectstack/platform-objects@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Minor Changes
diff --git a/packages/services/service-messaging/package.json b/packages/services/service-messaging/package.json
index c347533f5c..02009ac1f2 100644
--- a/packages/services/service-messaging/package.json
+++ b/packages/services/service-messaging/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/service-messaging",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "Messaging Service for ObjectStack — outbound notification dispatch (ADR-0012). Ships the MessagingChannel registry, emit() fan-out, and the always-on inbox channel; other channels (email/webhook/push/IM) plug in.",
   "type": "module",
diff --git a/packages/services/service-package/CHANGELOG.md b/packages/services/service-package/CHANGELOG.md
index 361721ed3d..109fab3052 100644
--- a/packages/services/service-package/CHANGELOG.md
+++ b/packages/services/service-package/CHANGELOG.md
@@ -1,5 +1,138 @@
 # @objectstack/service-package
 
+## 17.0.0-rc.4
+
+### Patch Changes
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [b746aa0]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [db0d53c]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [d9971d3]
+- Updated dependencies [eb3e650]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [46365ab]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [c5adfe1]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [51a587d]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [946a131]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/core@17.0.0-rc.4
+  - @objectstack/metadata-core@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Patch Changes
diff --git a/packages/services/service-package/package.json b/packages/services/service-package/package.json
index 6de6a06c5f..d5fb0960ff 100644
--- a/packages/services/service-package/package.json
+++ b/packages/services/service-package/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/service-package",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "Package management service for ObjectStack — publish, install, and manage packages",
   "type": "module",
diff --git a/packages/services/service-queue/CHANGELOG.md b/packages/services/service-queue/CHANGELOG.md
index e52af87206..04dfb24751 100644
--- a/packages/services/service-queue/CHANGELOG.md
+++ b/packages/services/service-queue/CHANGELOG.md
@@ -1,5 +1,258 @@
 # @objectstack/service-queue
 
+## 17.0.0-rc.4
+
+### Minor Changes
+
+- e98fb14: fix(service-queue): `sys_job_queue` no longer grows forever — `completed` rows expire on a declared 7-day retention (#5179)
+
+  `DbQueueAdapter` marked a delivered message `status: 'completed'` and then
+  **nothing ever touched that row again**. `purge()` had zero production callers
+  (tests only), `purgeFailed()` is a manual dead-letter API, and the object
+  declared no lifecycle policy at all — so every queue delivery left a permanent
+  row, which since #5160 means one permanent row per queued email.
+
+  `sys_job_queue` now declares an ADR-0057 policy and the platform
+  `LifecycleService` enforces it on its existing hourly sweep:
+
+  ```ts
+  lifecycle: {
+    class: 'transient',
+    retention: { maxAge: '7d', onlyWhen: { status: 'completed' } },
+  }
+  ```
+
+  **Only `completed` rows are swept.** `pending` / `running` are live work, and
+  `failed` / `dlq` are the dead-letter queue — they exist to wait for a human, so
+  they are never deleted automatically at any age. `listFailed()` / `replay()` /
+  `purgeFailed()` remain the only way a dead letter leaves the table. This is
+  also why the policy is `retention` (age + row filter) rather than a `ttl` on
+  `completed_at`: TTL has no row filter, and `dlq` rows stamp `completed_at` too.
+
+  **No new configuration, and no new sweeper.** ADR-0057 §3.3 puts one reaper in
+  the platform rather than one per plugin — the same call the sibling
+  `sys_job_run` (30d) already makes. Any kernel with a data engine already runs
+  it, its per-sweep `[lifecycle] sweep: … ~N rows reaped` line now accounts for
+  this table too, and the window is overridable per environment through the
+  `lifecycle` settings namespace without touching code.
+
+  **The dedup window is now an enforced invariant, not a coincidence.** Publish
+  dedups against a terminal row by comparing its `created_at` to
+  `idempotencyWindowMs` (default 24h), and the reaper cuts off on that same
+  `created_at` axis — so retention (7d) ≥ dedup window is what keeps "duplicate
+  publishes inside the window are suppressed" true. `DbQueueAdapter` reads the
+  declared window (new export `completedRetentionWindowMs()`) and **throws at
+  construction** if `idempotencyWindowMs` is configured longer than it, instead of
+  silently degrading into duplicate deliveries days later. If you raise
+  `idempotencyWindowMs` past 7 days, raise the object's declared retention (or the
+  `lifecycle` settings override) to match — the error message names both numbers.
+
+  `class: 'transient'` is deliberate: `telemetry`/`event`/`audit` classes
+  relocate their table to the dedicated `telemetry` datasource wherever one is
+  registered (ADR-0057 §3.6), and moving a live work queue's storage would be a
+  migration, not a cleanup.
+
+### Patch Changes
+
+- 7c2f7dd: fix(objectql,service-queue): a `lifecycle` settings override can no longer undercut a consumer's retention floor (#5195)
+
+  ADR-0057 P4 lets an operator override any object's retention window per
+  environment and per tenant through the `lifecycle` settings namespace. Until now
+  the only validation on that override was **does it parse** — and a retention
+  window is not only the operator's business: other code can depend on the rows
+  still being there.
+
+  `sys_job_queue` is the worked example. `DbQueueAdapter` deduplicates publishes by
+  comparing a terminal row's `created_at` against its idempotency window, so the
+  dedup check only means anything while that row still exists; #5179 made the
+  ordering an invariant by refusing, at construction, an idempotency window longer
+  than the object's **declared** retention. A settings override the constructor
+  cannot see walks straight around it:
+
+  ```jsonc
+  // lifecycle → retention_overrides
+  { "sys_job_queue": { "maxAge": "1h" } }
+  ```
+
+  completed rows are reaped an hour after they are written, publish keeps
+  deduplicating against 24h, and duplicate deliveries resume **with nothing in any
+  log**.
+
+  **New: retention floors.** A consumer may now declare, at runtime, the shortest
+  window its own contract survives:
+
+  ```ts
+  lifecycle.registerRetentionFloor("sys_job_queue", {
+    policy: "retention", // or 'ttl'
+    minWindowMs: 24 * 60 * 60 * 1000,
+    declaredBy: "com.objectstack.service.queue",
+    consequence: "…what silently breaks below it",
+    remedy: "…the settings change that makes an override legal",
+  });
+  ```
+
+  - An override below the floor — **global or tenant-scoped** — is **rejected**,
+    and the declared window keeps running. Not clamped to the floor: clamping
+    would enforce a third number written in neither the declaration nor the
+    settings, and that number would move whenever an unrelated package changed
+    its floor. Rejection has exactly one fallback, the declaration, which is
+    already how an unparseable override resolves.
+  - The rejection is `error`-level and carries both the consequence and the fix,
+    because what it prevents leaves the system looking entirely healthy. It is
+    also on the sweep report as `LifecycleSweepReport.floorViolations` — machine-
+    readable, every sweep.
+  - A **declared** window below a registered floor is reported the same way and
+    still enforced: refusing to reap would trade a broken consumer contract for
+    the unbounded table #5179 just closed.
+  - Objects with no registered floor are completely unaffected — P4 overrides
+    behave exactly as before.
+
+  Floors are runtime wiring, not spec surface (the same call ADR-0057's reap-guard
+  amendment makes), plus a reason of their own: the queue's floor **is**
+  `DbQueueAdapterOptions.idempotencyWindowMs`, a per-kernel construction option, so
+  a static key on the object's `lifecycle` block could only ever be a second copy
+  of it that drifts. No `packages/spec` change.
+
+  `QueueServicePlugin` registers `sys_job_queue`'s floor on `kernel:ready`,
+  carrying the window the adapter was actually constructed with — so a non-default
+  `db.idempotencyWindowMs` is covered too. The ordering is now enforced from both
+  sides: the constructor rejects a too-long `idempotencyWindowMs`, the floor
+  rejects a too-short `maxAge`.
+
+  New exports from `@objectstack/objectql`: `LifecycleRetentionFloor`,
+  `LifecycleFloorViolation`, plus `LifecycleService.registerRetentionFloor()`.
+  `LifecycleLoggerLike` gained an optional `error()` (absent ⇒ falls back to
+  `warn`), and `LifecycleSweepReport` gained `floorViolations`.
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [b746aa0]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [d9971d3]
+- Updated dependencies [eb3e650]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [e98fb14]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [1b9a53b]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [46365ab]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [c5adfe1]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [f104bab]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/core@17.0.0-rc.4
+  - @objectstack/platform-objects@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Patch Changes
diff --git a/packages/services/service-queue/package.json b/packages/services/service-queue/package.json
index e44c851185..c2dbc6c20f 100644
--- a/packages/services/service-queue/package.json
+++ b/packages/services/service-queue/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/service-queue",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "Queue Service for ObjectStack — implements IQueueService with in-memory and durable DB-backed (sys_job_queue) adapters",
   "type": "module",
diff --git a/packages/services/service-realtime/CHANGELOG.md b/packages/services/service-realtime/CHANGELOG.md
index 432d79156d..a013f75752 100644
--- a/packages/services/service-realtime/CHANGELOG.md
+++ b/packages/services/service-realtime/CHANGELOG.md
@@ -1,5 +1,138 @@
 # @objectstack/service-realtime
 
+## 17.0.0-rc.4
+
+### Patch Changes
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [b746aa0]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [d9971d3]
+- Updated dependencies [eb3e650]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [e98fb14]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [1b9a53b]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [46365ab]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [c5adfe1]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [f104bab]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/core@17.0.0-rc.4
+  - @objectstack/platform-objects@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Patch Changes
diff --git a/packages/services/service-realtime/package.json b/packages/services/service-realtime/package.json
index 0ee819b551..13e3237e3b 100644
--- a/packages/services/service-realtime/package.json
+++ b/packages/services/service-realtime/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/service-realtime",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "Realtime Service for ObjectStack — implements IRealtimeService with WebSocket and in-memory pub/sub",
   "type": "module",
diff --git a/packages/services/service-settings/CHANGELOG.md b/packages/services/service-settings/CHANGELOG.md
index 2601d2eeb2..9892da6c00 100644
--- a/packages/services/service-settings/CHANGELOG.md
+++ b/packages/services/service-settings/CHANGELOG.md
@@ -1,5 +1,488 @@
 # @objectstack/service-settings
 
+## 17.0.0-rc.4
+
+### Minor Changes
+
+- 586d6f7: feat(auth): `membership_policy` is a platform setting, and sign-up and backfill read one source (#5152)
+
+  **What a new user joins is now configurable at runtime.** ADR-0093's
+  `membershipPolicy` decides whether a freshly created user is auto-bound to the
+  deployment's default organization (`auto`) or gets membership only from an
+  explicit act — creating a workspace, accepting an invitation, an admin adding
+  them, SSO just-in-time provisioning (`invite-only`). Until now it was settable
+  **only** as an `AuthPlugin` constructor option, and the AuthPlugin a self-hosted
+  stack gets is injected by the CLI, which passes no such option and has no env
+  fallback. Every self-hosted deployment therefore ran `auto`, with no way to say
+  otherwise. `invite-only` was, in practice, unreachable outside a custom host.
+
+  It is now `auth.membership_policy` in the platform settings — a two-value select
+  (`auto` / `invite-only`, default `auto`) alongside `signup_enabled`, which it
+  pairs with: one says whether people may self-register, the other says what they
+  join when they do. Set it in Setup → Authentication → Membership, or pin it
+  per-deployment with `OS_AUTH_MEMBERSHIP_POLICY`. It applies **without a
+  restart** — the existing `settings.subscribe('auth', …)` re-application seam
+  carries it, the same one the password-policy keys ride.
+
+  **No behaviour changes unless you set it.** Only an _explicit_ value applies;
+  the manifest's `auto` default is a UI default and never masks a deployment that
+  configured the policy in code. A stack that sets nothing keeps today's
+  auto-binding exactly.
+
+  **Bug fix — the two membership paths read one source.** Sign-up (the reconciler
+  in better-auth's `user.create.after`) read the AuthManager's live config, while
+  the ADR-0093 D6 backfill of pre-existing member-less users read the plugin's
+  **constructor options**. Wiring a setting to the first and not the second would
+  have produced "sign-up honours the new policy, backfill still runs the old one"
+  — and the backfill binds in **bulk**, so it is the more dangerous half. Both now
+  resolve the policy through the new `AuthManager.getMembershipPolicy()`, and the
+  backfill waits for the settings namespace to bind before its first pass (the two
+  `kernel:ready` hooks fire in registration order, which was the wrong order).
+
+  **An invalid value is rejected, not coerced.** `PUT /api/settings/auth` refuses
+  a policy outside the declared option table (`invalid_option`, naming the allowed
+  set). A value arriving from `OS_AUTH_MEMBERSHIP_POLICY` — which bypasses that
+  validation — is logged at `error` and **ignored**, leaving the deployment's
+  current policy in force; it is never silently read as `auto`, because that would
+  leave an operator believing a wall is up while every sign-up is auto-bound.
+
+  New public API on `@objectstack/plugin-auth`: `AuthManager.getMembershipPolicy()`,
+  plus `MEMBERSHIP_POLICIES` and `isMembershipPolicy()` from `reconcile-membership`.
+
+- 9c4f174: feat(plugin-email): durable email delivery through `sys_job_queue`, opt-in (#5160)
+
+  `IEmailService.send()` has always delivered **inline**: the SMTP session ran
+  inside the caller's `await`, and `EmailService`'s retry loop lived in the same
+  process — so a crash between the attempt and the retry dropped the message with
+  no trace beyond a `sys_email` row stuck at `queued`. The pieces for a durable
+  path all existed (`sys_job_queue`, the `DbQueueAdapter`, an `email.send.async`
+  subscriber) but nothing in the repo ever published to that topic.
+
+  **New: `queueDelivery`.** With it on, `send()` persists the `sys_email` row,
+  publishes an `email.send.async` job **referencing that row**, and returns
+  `{ status: 'queued' }` immediately. A worker delivers the row and finalizes it
+  in place (`sent` + `message_id`, or `failed` + `error`); the queue retries with
+  exponential backoff (1s → 5min cap) and dead-letters the job when the attempts
+  run out, so a restart resumes delivery instead of losing it. The `'queued'`
+  status was already in `EmailDeliveryStatus` — no spec change.
+
+  Three ways to turn it on, all default-off:
+
+  - `new EmailServicePlugin({ queueDelivery: true })`
+  - `OS_EMAIL_QUEUE_ENABLED=true` (or `config.email.queueDelivery`) on `os serve`
+  - Settings → Mail → **Durable queue delivery**, hot-applied without a restart
+
+  **One retry budget, not two.** `retries` keeps its meaning — total attempts are
+  `retries + 1` in both modes. Inline it drives the in-process loop; queued it
+  becomes the queue's `maxAttempts` and the per-row loop is pinned to one attempt
+  per delivery. Turning the toggle on changes _where_ a retry happens (durable,
+  backed off) and never _how many_ happen, so the two layers cannot multiply.
+
+  **Fixed in the same change: the `email.send.async` subscriber inserted a new
+  `sys_email` row per delivery.** It called `send()` with the message, so a job
+  the queue retried five times left five rows — four permanently `failed`, none
+  carrying the real attempt count. It now delivers the referenced row via
+  `deliverPersistedRow`, so one message is one row and `attempt_count`
+  accumulates on it. Messages published in the old shape (a bare `SendEmailInput`)
+  are still accepted and delivered inline for a migration window.
+
+  Boundaries worth knowing before you switch it on:
+
+  - **"Send test email" always sends inline**, in every mode — the button has to
+    report the provider's own answer (`535 …`), and "queued" is exactly the
+    non-answer #5087 removed from it.
+  - **Messages with attachments or custom headers are delivered inline**, because
+    `sys_email` has no columns for them and a queued copy would arrive stripped.
+    Queueing them is tracked separately; this ships the loss-free behaviour.
+  - **A declaration that cannot be honoured fails the boot.** `queueDelivery: true`
+    from the constructor or `OS_EMAIL_QUEUE_ENABLED` with no durable queue
+    registered (or with `persist: false`) throws on `kernel:ready`, naming the
+    fix — the #5132 judgement, applied to durability. The **settings toggle** is
+    the opposite trade: it logs at `error` and keeps sending inline, because one
+    save must not stop the mail.
+  - The kernel's built-in in-memory `queue` fallback does **not** count as a
+    durable queue: it delivers synchronously with no retry or DLQ, so publishing
+    to it would report `queued` for a message nothing could ever recover. Mount
+    `@objectstack/service-queue` over an ObjectQL engine (the `queue` capability
+    does this on `os serve`) to get the `sys_job_queue`-backed adapter.
+
+  Leaving `queueDelivery` unset keeps today's behaviour byte for byte.
+
+- 8597a7d: fix(service-settings,plugin-email): the mail provider dropdown lists only providers that actually deliver (#5094)
+
+  **Settings → Mail → Provider** offered `SMTP | SendGrid | Amazon SES | Postmark`.
+  `@objectstack/plugin-email` has never carried a SendGrid or an SES transport —
+  `makeTransport` knows `log` / `resend` / `postmark` / `smtp` and nothing else. So
+  selecting either of the two validated, saved, showed a success toast, and then
+  delivered no mail at all: the same declared-but-not-delivered gap #5087 closed
+  for SMTP, one field to the left.
+
+  The same field broke the invariant in the other direction at the same time:
+  **`resend` has shipped a working transport all along and was not on the list**,
+  so nobody could pick the one HTTP provider that worked.
+
+  **The dropdown is now `SMTP | Resend | Postmark | None (log only — no real
+delivery)` — exactly the set `makeTransport` can build.** No email capability was
+  removed with SendGrid and SES. Both publish SMTP endpoints, and #5087 shipped a
+  real `SmtpTransport`, so both are configured today as `smtp`:
+
+  | provider   | host                                | port | credentials                                                                        |
+  | :--------- | :---------------------------------- | :--- | :--------------------------------------------------------------------------------- |
+  | SendGrid   | `smtp.sendgrid.net`                 | 587  | username `apikey`, password = your API key                                         |
+  | Amazon SES | `email-smtp.<region>.amazonaws.com` | 587  | SES **SMTP credentials** (generated in the SES console — not your AWS access keys) |
+
+  The provider field's own description says this, so the migration is in front of
+  whoever goes looking for the option that disappeared.
+
+  `log` is listed rather than hidden. It is the one option that does not deliver —
+  but it does not pretend to: the label says so, `LogTransport` still records every
+  message to `sys_email`, and "Send test email" answers `ok: false` for it. That
+  gives an operator the deliberate, visible opt-out AGENTS.md asks a degradation to
+  be, instead of expressing "no outbound mail" as a half-filled SMTP form. It is
+  also what makes _offered_ and _deliverable_ the same set rather than merely
+  overlapping — which is the property a test can hold.
+
+  **Already saved `sendgrid` or `ses`? Nothing breaks and nothing goes quiet.** The
+  stored value outlives the dropdown, so `applyMailSettings` now recognises it
+  explicitly: the previous transport is kept (a settings row written by an older
+  release must never fail a boot), and the server logs at `error` with both halves
+  AGENTS.md requires — the consequence (_no mail is delivered through it_) and the
+  fix (the SMTP settings above), not a bare "unknown provider". It is checked
+  _before_ the API-key check, because "set an API key" is the wrong instruction for
+  a provider that has nothing to hand a key to. "Send test email" refuses the same
+  way and sends nothing. Switching the provider to `smtp` and saving recovers the
+  transport without a restart.
+
+  Two smaller corrections in the same field:
+
+  - `api_key` is now shown and required for exactly `resend` and `postmark`
+    (`provider === 'resend' || provider === 'postmark'`). It was `provider !==
+'smtp'`, which only worked because every non-SMTP option happened to be an
+    HTTP API; `required` is enforced server-side wherever the field is visible, so
+    that expression would have refused to save "None (log only)" until an API key
+    it never reads had been typed in.
+  - The built-in `mail/test` fallback (the one that runs when no email plugin is
+    mounted) rejects any `provider` outside the manifest's own option list instead
+    of answering "the form is well-formed".
+
+  **Held by a test, in both directions.** `EMAIL_TRANSPORT_PROVIDERS` is now a
+  runtime array (the `EmailTransportProvider` union is derived from it), and
+  `plugin-email`'s `mail-manifest-providers.contract.test.ts` asserts set equality
+  between it and the manifest's option values, then builds a real transport for
+  each. Adding an option without a transport fails; adding a transport without an
+  option fails. `RETIRED_EMAIL_PROVIDERS` / `isEmailTransportProvider` /
+  `unsupportedProviderFix` are exported alongside it for hosts that surface the
+  same guidance.
+
+- 9c90ea0: feat(sms): 短信全局日发送配额 —— 成本总量闸 (#2814)
+
+  #2780 给 OTP 端点落了**按号码**的防滥用（60s 冷却 + 每号码 5 条/小时）。那挡住的是「一个号码花多少钱」，挡不住「这套部署一天花多少钱」：攻击者轮换上万个不同号码时，每个号码都稳稳待在自己的预算里，而日累计账单没有任何上限——这正是 SMS pumping / toll fraud 的典型打法。更要紧的是，按号码那道闸住在 better-auth 的 `hooks.before` 里，只看得见 auth 端点：`notify(channels:['sms'])` 与邀请短信从旁边直接走过去，一条都不计数。
+
+  本次新增一道**总量**闸，扣减点放在所有出站短信本来就必经的那一处 —— `SmsService.send()`。OTP、邀请、messaging `sms` channel 三条路无论从哪扇门进来，都记在同一本账上。
+
+  ## 新增设置项
+
+  `sms` 命名空间新增 `daily_quota`（Daily send limit，number，默认 `0` = 不限）：这套部署每个 **UTC 自然日**允许发出的短信总条数。超出后拒发，直到 00:00 UTC。env 覆盖沿用既有的每键机制，无需额外接线：`OS_SMS_DAILY_QUOTA=2500`。
+
+  `0` 是出厂姿态，所以升级本身不改变任何现有部署的发送行为——闸门要由运营者显式配置才会闭合。
+
+  ## Observable behaviour change
+
+  **配置配额后，发送可能被拒**，两条路径的表现分别是：
+
+  - OTP / 邀请路径 —— `SendSmsResult.status='failed'`，`error` 为 `TOO_MANY_REQUESTS: daily SMS quota exhausted`。刻意与按号码闸抛出的 `TOO_MANY_REQUESTS` 用同一个码，且**不带任何剩余额度细节**：从外面看，两道墙必须长得一样，攻击者不该能试探出自己撞的是哪一道。
+    ⚠️ 但这个码**目前到不了 HTTP 调用方**：`AuthManager.deliverPhoneOtp` 把它重抛成普通 `Error`，而 better-call 对非 `APIError` 一律回 500（实测，见 #6039）。也就是说 OTP 端点上，按号码闸回 429、总量闸回 500。补齐要动 plugin-auth，已单独立案。
+  - messaging `sms` channel —— `SendResult.ok=false`，且 `classifyError` 返回 `'rate_limited'`（此前一律 `'retryable'`）。投递落进 outbox 走退避重试 / 死信，不会被静默丢弃；`rate_limited` 与 `retryable` 走同一条重试阶梯，但把「额度用尽」与「网关抖动」在投递记录上区分开。
+
+  ## 计数落在哪里
+
+  复用仓内唯一那份定窗计数（`incrementFixedWindow`）与它的惰性存储解析（`createLazyCounterStore`，#4772/#4790），不写第三份：
+
+  - 有 kernel `cache` 服务时计在共享 cache（集群共享与否取决于 cache 本身）；
+  - 解析不到时降级为有界的进程内计数，并由解析器**点名**打一条 warn，说明降级的代价（N 节点部署最多可花 N× 配额）；
+  - 解析在**计数被消费时**发生，而非插件 init —— 后注册的 cache 也能在下一次发送时被接上（#4772 的坑）。
+
+  窗口是 UTC 自然日，且由两个机制同时保证：计数键带 UTC 日期（`sms-daily-sends:2026-08-06`），窗口开启时的 TTL 恰为距下一个 UTC 午夜的秒数。任一机制单独也能翻窗，合起来则不可能互相矛盾。
+
+  ## 两条刻意的姿态
+
+  - **fail-open**：计数存储读不到时，闸门**放行**并打一次 warn。短信成本闸不能把登录拖下水（#2814 诉求 4）。
+  - **配额值的钳制在消费侧**：manifest 上的 `min: 0` 今天并不被 `validatePatch` 执行（#5932），所以负值 / `NaN` / `Infinity` / 非数字都会原样抵达读取方。这些一律降级为 `0`（不限）并**点名**打 warn，而不是拒发、也不是替运营者编一个别的默认值——一个设置表单里的手误不该变成手机登录的全站故障，而编一个没人声明过的上限只会把手误藏进看似合理的行为里。
+
+  ## 不在本次范围
+
+  诉求中的**每租户日配额**（`daily_quota_per_tenant`）未实现：`SendSmsInput`（`@objectstack/spec/contracts`）不携带任何租户标识，而在 service 侧另造一个只此一家的拼法就是 Prime Directive #12 明令禁止的影子契约。租户维度要么落在 spec 契约上，要么不落——详见 #2814 上的讨论。
+
+### Patch Changes
+
+- 4022b78: Settings: an `OS_*` env override is now checked against the specifier's declared `options` table (#5204)
+
+  A manifest's `options` table has been enforced on the write path since #5131, but
+  `SettingsService.get()` produced an effective value by a second route that never
+  consulted it: an `OS_*` override was reshaped by the default's type and returned
+  straight from the top of the cascade with `locked: true`. So the providers #5094 and
+  #5133 retired from `mail.provider` could walk back in through the one door with no
+  gate on it — `OS_MAIL_PROVIDER=sendgrid` reached the mail plugin unchallenged — and a
+  plain typo such as `OS_BRANDING_THEME_MODE=drak` was served to every consumer as a
+  normal value with normal-looking provenance, each consumer left to improvise.
+
+  An override whose value the table does not declare is now **ignored** rather than
+  repaired: the value falls through to the next layer of the cascade (a stored
+  global/tenant/user value, else the manifest default), and the read API reports that
+  layer honestly instead of claiming `source: 'env'` for a value not in force. The
+  rejection is logged once at `error`, naming the variable, the rejected value, the legal
+  value set and the consequence. The same audit runs at `registerManifest`, so a
+  misconfigured deployment learns at boot rather than whenever somebody first opens the
+  settings page.
+
+  Registration **reports but never refuses**: option tables move, a pin that was legal
+  the day it was written must not turn an upgrade into a crash-on-start.
+
+  Two behaviour notes for anyone relying on the old shape:
+
+  - Keys with no declared option table are untouched — text, boolean, number and
+    password overrides behave exactly as before. The check applies only to
+    `select`/`radio`/`multiselect` specifiers that declare a non-empty table.
+  - A **rejected** override no longer pins its key against writes. `setMany` used to
+    refuse on the mere presence of the variable; judged by presence, an ignored value
+    would have left the key configurable by nothing at all — env value discarded, UI
+    refused with `SETTINGS_LOCKED`, and `get()` reporting `locked: false` to a settings
+    page whose save would then fail. An override that _is_ in force still locks the key,
+    unchanged.
+
+- 82a06af: fix(service-settings): a settings `select` now rejects values outside its declared `options` (#5131)
+
+  `SettingsService.validatePatch` enforced two of the constraints a settings
+  manifest declares — `required` and `pattern` — and skipped the third. A
+  specifier's `options` table never took part in save-time validation, so any
+  string at all could be written into a dropdown field:
+
+  ```ts
+  await svc.setMany("mail", { provider: "sendgrid", from_email: "a@b.com" }); // stored
+  ```
+
+  Going through the console this was unreachable: the dropdown only ever emits a
+  value from the table. But `PUT /api/settings/:ns` is an authorizable public
+  surface, and scripts, migration tools and AI-authored bootstrap code write it
+  directly — where the bad value was accepted, persisted and read back **in
+  silence**, leaving every consumer to improvise its own answer for an
+  enumeration member that does not exist. It was not `mail`-specific:
+  `storage.adapter`, `sms.provider`, `ai.provider`, `localization.date_format` and
+  every other `select` behaved the same way.
+
+  This is the API-side gate that #5094 was missing. That change retired
+  `sendgrid` / `ses` from the `mail` provider table because this server cannot
+  deliver through them — with no write-side enforcement, the values it had just
+  retired could be written straight back in the same afternoon.
+
+  **Now:** a `select` / `radio` / `multiselect` value that is not a member of the
+  declared table is rejected with a `FieldError` whose `code` is `invalid_option`
+  and whose `constraint` carries the allowed set (`{ allowed: 'smtp, resend,
+postmark, log' }`), so a client composes its own message instead of parsing
+  ours. The enforced set is the spec's own: `SpecifierSchema` already _requires_ a
+  non-empty `options` on exactly those three types, so declared and enforced name
+  one list rather than two that can drift.
+
+  Two deliberate limits keep this from breaking workspaces that already carry
+  drift:
+
+  - **The check is gated on TOUCH**, like `required` and `pattern` before it. A
+    value that pre-dates the current option table only fails the patch that
+    writes that key — editing `from_name` is not rejected because a stale
+    `provider` sits in the store. The opposite rule would lock every workspace
+    with historical drift out of its own settings page entirely, which is worse
+    than the gap being closed. Resets (all-null patches) are never blocked.
+  - **A specifier that declares no option table is left alone.** It cannot say
+    what is legal, so it stays lenient rather than rejecting every write.
+
+  Values are compared in string form, so an option declared `value: 30` still
+  matches after a round trip through JSON or a form post. There is no opt-out: a
+  manifest that needs to accept custom values would declare that explicitly in
+  the spec, not rely on a tolerant consumer.
+
+- 41c3b48: feat(plugin-email): real SMTP delivery — `SmtpTransport`, settings hot-swap, and a `mail/test` that actually sends (#5087)
+
+  The **Mail Delivery** settings page has always defaulted to SMTP and offered a
+  full host / port / TLS / username / password form. Nothing behind it delivered:
+  `applyMailSettings` treated `provider: 'smtp'` as a no-op ("transport
+  unchanged"), `mail/test` answered `ok: true, "Configuration looks valid … Wire
+@objectstack/plugin-mail for actual delivery"` — a success toast for a message
+  nobody sent, naming a package that has never existed — and the code pointed
+  operators at `@objectstack/plugin-mail-smtp`, which is not in this repo or on
+  npm. A workspace that selected SMTP got a green form, a green test button, and
+  mail that only ever reached the log and the `sys_email` table. For deployments
+  in China this left **no** working channel at all: Resend and Postmark are
+  overseas HTTPS SaaS with unreliable reach and deliverability to QQ / 163 /
+  enterprise mailboxes, where SMTP is the normal path (Aliyun DirectMail, Tencent
+  SES, corporate mail servers).
+
+  **`SmtpTransport` now ships in `@objectstack/plugin-email`** (ADR-0012: SMTP in
+  core, implemented with `nodemailer`). `nodemailer` is a real dependency but is
+  imported **lazily on the first send**, so deployments that never select SMTP —
+  and non-Node runtimes — never load `node:net` / `node:tls`.
+
+  Three doors reach it, all sharing one options reader so they cannot drift:
+
+  - **Settings → Mail** (`smtp_host` / `smtp_port` / `smtp_secure` / `smtp_user` /
+    `smtp_password`) hot-swaps the live transport on save, no restart.
+  - **`os serve`** via `OS_EMAIL_PROVIDER=smtp` plus the new `OS_EMAIL_SMTP_HOST` /
+    `_PORT` / `_SECURE` / `_USER` / `_PASSWORD` (or `config.email.options`).
+  - **Constructor**: `new EmailServicePlugin({ provider: 'smtp', providerOptions:
+{ host, port, secure, user, password } })`.
+
+  TLS is one toggle with the wire behaviour derived from the port, as providers
+  document it: on `465` implicit TLS (SMTPS); on any other port a **required**
+  STARTTLS upgrade, so a server that refuses to upgrade fails the send instead of
+  leaking credentials over a cleartext socket; `secure: false` connects in the
+  clear and upgrades only when STARTTLS is offered.
+
+  **Failure is loud everywhere, because a silent fallback is the bug this fixes.**
+  On the construction path (CLI / plugin options) a `smtp` provider with no host
+  **throws** and the boot fails — it no longer degrades into a LogTransport that
+  reports every send as successful. On the settings hot-swap path a save can never
+  kill a running server, so the previous transport is kept — but the failure is
+  logged at `error` naming the consequence and the fix, and **`mail/test` now
+  performs a real delivery** through the settings on screen and reports the SMTP
+  server's own words (`535 … authentication failed`) instead of a green toast. The
+  built-in fallback `mail/test` handler (used only when no email plugin is
+  mounted) answers `ok: false` and says plainly that nothing was sent.
+
+  Nothing to migrate: `log`, `resend` and `postmark` behave exactly as before, and
+  a deployment that never selects `smtp` is unaffected.
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [64cd010]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [b746aa0]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [08f93bc]
+- Updated dependencies [d9971d3]
+- Updated dependencies [eb3e650]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [02dc076]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [e98fb14]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [1b9a53b]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [46365ab]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [c5adfe1]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [f104bab]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/types@17.0.0-rc.4
+  - @objectstack/core@17.0.0-rc.4
+  - @objectstack/platform-objects@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Patch Changes
diff --git a/packages/services/service-settings/package.json b/packages/services/service-settings/package.json
index 6fc0e82142..e95fbc27cc 100644
--- a/packages/services/service-settings/package.json
+++ b/packages/services/service-settings/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/service-settings",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "Settings service for ObjectStack — manifest registry + K/V resolver (OS_* env > Tenant > User > Default) + REST routes. See ADR-0007.",
   "type": "module",
diff --git a/packages/services/service-sms/CHANGELOG.md b/packages/services/service-sms/CHANGELOG.md
index 613ef5cdd9..1a393d2211 100644
--- a/packages/services/service-sms/CHANGELOG.md
+++ b/packages/services/service-sms/CHANGELOG.md
@@ -1,5 +1,261 @@
 # @objectstack/service-sms
 
+## 17.0.0-rc.4
+
+### Minor Changes
+
+- de770bf: fix(cli,service-sms)!: `OS_SMS_PROVIDER=twilo` now fails the boot instead of silently becoming the log transport (#5713)
+
+  **BREAKING for one configuration: a provider tag no SMS transport can build.**
+  `os serve` used to hand `OS_SMS_PROVIDER` (or `config.sms.provider`) straight to
+  `SmsServicePlugin` with nothing to compare it against. The plugin then caught the
+  `makeSmsTransport: unknown provider 'twilo'` throw, substituted `LogSmsTransport`,
+  and booted normally — measured, not inferred:
+
+  ```
+  new SmsServicePlugin({ provider: 'twilo' }).init(ctx)
+    booted_without_throw: true            transport_class: 'LogSmsTransport'
+    isConfigured():       false           logger.warn × 1, logger.error × 0
+    service.send(…)    →  { status: 'sent', messageId: 'dev-sms-…' }
+  ```
+
+  So a phone-OTP sign-in answered "code sent", the user waited for an SMS that was
+  never dispatched, and the one `warn` line scrolled past in the boot log. That is
+  the declared-but-not-delivered shape of Prime Directive #10, and the same one
+  #5132 closed for **mail** in the neighbouring arm of the very same capability
+  loop.
+
+  Three gates already guard the `sms` provider value and none of them could see
+  this path: the `sms` settings namespace declares `provider` as a `select` with an
+  options table, #5131 enforces that table on the write path, and #5204 closed the
+  `SettingsService` env-override branch. All three live behind `SettingsService` —
+  this read happens while the kernel is being assembled, _before_ a settings
+  service exists.
+
+  **`resolveSmsCapabilityArg` now refuses a provider tag outside
+  `log` / `aliyun` / `twilio`**, the way its neighbouring `resolveEmailCapabilityArg`
+  already did, and the capability loop turns that into the loud failure it should
+  be — a hard boot error when the app declared `requires: ['sms']`, otherwise a
+  `console.error` and no SMS service.
+
+  **What it deliberately does NOT do:** demand credentials. Unlike mail, SMS
+  provider credentials are not a boot-time input — the `sms` settings namespace
+  binds them at `kernel:ready`, and that is their documented home. A bare
+  `OS_SMS_PROVIDER=twilio` on a host whose Twilio keys live in Settings is a
+  complete configuration and passes through untouched. `SmsServicePlugin`'s own
+  fallback is likewise untouched: for a _known_ provider with incomplete
+  constructor credentials it is correct (the settings bind can still swap in a
+  working transport), and it remains the last line of defence for hosts that
+  construct the plugin themselves. `os serve` simply stops feeding it input it can
+  never use.
+
+  **Who is affected:** deployments that set `OS_SMS_PROVIDER` (or
+  `config.sms.provider`) to a value outside the supported three — in practice a
+  typo, or a provider that was never implemented — and relied on the fallback to
+  boot. An unset `OS_SMS_PROVIDER` still defaults to `log`; every supported tag
+  still boots with or without credentials.
+
+  **Migration — one line, either direction:**
+
+  - the environment is _not_ meant to send SMS → `OS_SMS_PROVIDER=log` (that
+    explicit value is the supported way to say so, and why refusing the others is
+    fair);
+  - the environment _is_ meant to send SMS → fix the tag to `aliyun` or `twilio`
+    and put the credentials in Settings → SMS Delivery (or
+    `config.sms.providerOptions`).
+
+  The error names the consequence and both fixes, per AGENTS.md's
+  degradation-log-level rule.
+
+  `@objectstack/service-sms` gains the vocabulary the CLI reads instead of
+  restating: `SMS_TRANSPORT_PROVIDERS` and `isSmsTransportProvider()`, with
+  `SmsProviderTag` now derived from the array rather than declared beside it. One
+  vocabulary, two consumers — a second literal list in the CLI is how the mail
+  settings dropdown and the mail transports drifted apart in the first place
+  (#5094).
+
+- 9c90ea0: feat(sms): 短信全局日发送配额 —— 成本总量闸 (#2814)
+
+  #2780 给 OTP 端点落了**按号码**的防滥用（60s 冷却 + 每号码 5 条/小时）。那挡住的是「一个号码花多少钱」，挡不住「这套部署一天花多少钱」：攻击者轮换上万个不同号码时，每个号码都稳稳待在自己的预算里，而日累计账单没有任何上限——这正是 SMS pumping / toll fraud 的典型打法。更要紧的是，按号码那道闸住在 better-auth 的 `hooks.before` 里，只看得见 auth 端点：`notify(channels:['sms'])` 与邀请短信从旁边直接走过去，一条都不计数。
+
+  本次新增一道**总量**闸，扣减点放在所有出站短信本来就必经的那一处 —— `SmsService.send()`。OTP、邀请、messaging `sms` channel 三条路无论从哪扇门进来，都记在同一本账上。
+
+  ## 新增设置项
+
+  `sms` 命名空间新增 `daily_quota`（Daily send limit，number，默认 `0` = 不限）：这套部署每个 **UTC 自然日**允许发出的短信总条数。超出后拒发，直到 00:00 UTC。env 覆盖沿用既有的每键机制，无需额外接线：`OS_SMS_DAILY_QUOTA=2500`。
+
+  `0` 是出厂姿态，所以升级本身不改变任何现有部署的发送行为——闸门要由运营者显式配置才会闭合。
+
+  ## Observable behaviour change
+
+  **配置配额后，发送可能被拒**，两条路径的表现分别是：
+
+  - OTP / 邀请路径 —— `SendSmsResult.status='failed'`，`error` 为 `TOO_MANY_REQUESTS: daily SMS quota exhausted`。刻意与按号码闸抛出的 `TOO_MANY_REQUESTS` 用同一个码，且**不带任何剩余额度细节**：从外面看，两道墙必须长得一样，攻击者不该能试探出自己撞的是哪一道。
+    ⚠️ 但这个码**目前到不了 HTTP 调用方**：`AuthManager.deliverPhoneOtp` 把它重抛成普通 `Error`，而 better-call 对非 `APIError` 一律回 500（实测，见 #6039）。也就是说 OTP 端点上，按号码闸回 429、总量闸回 500。补齐要动 plugin-auth，已单独立案。
+  - messaging `sms` channel —— `SendResult.ok=false`，且 `classifyError` 返回 `'rate_limited'`（此前一律 `'retryable'`）。投递落进 outbox 走退避重试 / 死信，不会被静默丢弃；`rate_limited` 与 `retryable` 走同一条重试阶梯，但把「额度用尽」与「网关抖动」在投递记录上区分开。
+
+  ## 计数落在哪里
+
+  复用仓内唯一那份定窗计数（`incrementFixedWindow`）与它的惰性存储解析（`createLazyCounterStore`，#4772/#4790），不写第三份：
+
+  - 有 kernel `cache` 服务时计在共享 cache（集群共享与否取决于 cache 本身）；
+  - 解析不到时降级为有界的进程内计数，并由解析器**点名**打一条 warn，说明降级的代价（N 节点部署最多可花 N× 配额）；
+  - 解析在**计数被消费时**发生，而非插件 init —— 后注册的 cache 也能在下一次发送时被接上（#4772 的坑）。
+
+  窗口是 UTC 自然日，且由两个机制同时保证：计数键带 UTC 日期（`sms-daily-sends:2026-08-06`），窗口开启时的 TTL 恰为距下一个 UTC 午夜的秒数。任一机制单独也能翻窗，合起来则不可能互相矛盾。
+
+  ## 两条刻意的姿态
+
+  - **fail-open**：计数存储读不到时，闸门**放行**并打一次 warn。短信成本闸不能把登录拖下水（#2814 诉求 4）。
+  - **配额值的钳制在消费侧**：manifest 上的 `min: 0` 今天并不被 `validatePatch` 执行（#5932），所以负值 / `NaN` / `Infinity` / 非数字都会原样抵达读取方。这些一律降级为 `0`（不限）并**点名**打 warn，而不是拒发、也不是替运营者编一个别的默认值——一个设置表单里的手误不该变成手机登录的全站故障，而编一个没人声明过的上限只会把手误藏进看似合理的行为里。
+
+  ## 不在本次范围
+
+  诉求中的**每租户日配额**（`daily_quota_per_tenant`）未实现：`SendSmsInput`（`@objectstack/spec/contracts`）不携带任何租户标识，而在 service 侧另造一个只此一家的拼法就是 Prime Directive #12 明令禁止的影子契约。租户维度要么落在 spec 契约上，要么不落——详见 #2814 上的讨论。
+
+### Patch Changes
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [7a40b7a]
+- Updated dependencies [7cf1531]
+- Updated dependencies [586d6f7]
+- Updated dependencies [2d14b35]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [93929c2]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [b746aa0]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [08f93bc]
+- Updated dependencies [d9971d3]
+- Updated dependencies [eb3e650]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [9fa6bab]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [61dc08e]
+- Updated dependencies [8dcf607]
+- Updated dependencies [b691ba9]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [46365ab]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [c5adfe1]
+- Updated dependencies [26e1029]
+- Updated dependencies [4addd9d]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [de113a4]
+- Updated dependencies [db8c285]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [b40f81c]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [ef8b1ff]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/core@17.0.0-rc.4
+  - @objectstack/plugin-auth@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Patch Changes
diff --git a/packages/services/service-sms/package.json b/packages/services/service-sms/package.json
index 33a4de0ed0..d7d5615571 100644
--- a/packages/services/service-sms/package.json
+++ b/packages/services/service-sms/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/service-sms",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "SMS service for ObjectStack — ISmsService + transport-pluggable outbound delivery (Aliyun / Twilio / log).",
   "main": "dist/index.js",
diff --git a/packages/services/service-storage/CHANGELOG.md b/packages/services/service-storage/CHANGELOG.md
index 2bcc80da06..814ce05942 100644
--- a/packages/services/service-storage/CHANGELOG.md
+++ b/packages/services/service-storage/CHANGELOG.md
@@ -1,5 +1,256 @@
 # @objectstack/service-storage
 
+## 17.0.0-rc.4
+
+### Major Changes
+
+- 718b229: fix(service-storage)!: a `sys_file` / `sys_upload_session` write that never landed no longer reports success (#5216)
+
+  `StorageMetadataStore` wrapped **all eight** of its `IDataEngine` calls in
+  `try { … } catch { /* ignore */ }` — no logger, no rethrow, no degradation flag.
+  Because `if (this.engine)` had already separated "no data engine wired" out,
+  those catches could only ever fire on a **runtime** failure of an engine that is
+  wired: a constraint violation, a connection blip, an RLS refusal, a table that
+  was never migrated. Every one of them was swallowed, and the store returned the
+  record it had just put in a process-local `Map`.
+
+  The result on `sys_file` — mostly-permanent business truth with compliance value
+  (#5202) — was the shape AGENTS.md → "Degradation log levels" exists to forbid:
+  the bytes landed in the storage backend, the metadata row **never existed**, and
+  `POST /api/v1/storage/upload/presigned` answered `200 { success: true }` with a
+  `fileId` naming nothing. A read in the same process then found the Map shadow,
+  so even a self-check looked healthy — until the worker recycled and the
+  attachment became permanently unaddressable, with not one line of log pointing
+  at the cause. On `sys_upload_session` the same swallow made multi-worker chunked
+  uploads die as unexplained stalls instead of a diagnosable error.
+
+  **What changes.** With a data engine wired, the engine is now the only store:
+
+  - **Writes** (`createFile`, `updateFile`, `deleteFile`, `createSession`,
+    `updateSession`, `deleteSession`) propagate the failure as a new
+    `StorageMetadataStoreError` instead of returning a value. Nothing is mirrored
+    into the `Map`, so there is no in-process shadow left behind to make a lost
+    write look like a landed one.
+  - **Reads** (`getFile`, `getSession`) distinguish a **miss** from an **outage**.
+    `findOne` returning nothing is still a miss and still returns `null` (the REST
+    layer answers 404, unchanged). An engine that _throws_ now propagates:
+    substituting this process's `Map` for an unreachable engine would dress a
+    stale or empty local guess up as the persisted answer, which under multiple
+    workers is a different wrong answer per worker.
+  - The process-local `Map` is now exactly what the class doc always claimed —
+    the stand-in for deployments with **no** engine wired (tests, dev). Behaviour
+    of `new StorageMetadataStore(null)` is unchanged in every respect.
+
+  **Breaking, and where it shows.** No API signature changed; what changed is that
+  these calls can now reject. Requests that previously received `200` over a lost
+  write receive `500 INTERNAL` from the existing storage route handlers (they
+  already wrapped every handler in `catch → sendError(500, 'INTERNAL', …)`, so no
+  route needed editing), and a read attempted during an engine outage answers
+  `500` rather than a false `404 FILE_NOT_FOUND`. If you call
+  `StorageMetadataStore` directly, the six write methods and the two read methods
+  may now throw `StorageMetadataStoreError` — `error.objectName`
+  (`sys_file` / `sys_upload_session`), `error.operation`
+  (`insert` / `update` / `delete` / `findOne`) and `error.cause` (the engine's own
+  failure) identify it, and `error.message` states the consequence and the fix.
+
+  There is nothing to migrate: no deployment can have been _relying_ on the old
+  behaviour, because the old behaviour produced no signal to rely on. What a
+  deployment may newly _see_ is a 500 that was previously an undetected data loss.
+  `StorageMetadataStoreError` and the `StorageMetadataOperation` type are exported
+  from `@objectstack/service-storage` for callers that want to tell a metadata
+  outage apart from any other 500.
+
+### Patch Changes
+
+- 1f1edc0: refactor(service-storage): drop `list(prefix)` from the local and S3 adapters — the implementation half of the #5540 contract retirement (#5541)
+
+  `IStorageService.list?(prefix)` was removed from the contract in `@objectstack/spec` 5.x
+  (#5540, ADR-0049 enforce-or-remove; analysis #5266). This removes what it left behind:
+  the two shipped adapters' own implementations, the tests that pinned them, and the
+  `'list'` label in each adapter's metrics vocabulary.
+
+  **Nothing in this repository ever called them.** The only in-repo call site was the
+  `SwappableStorageService` pass-through, deleted with the contract member in #5540. After
+  that deletion the surviving references were the two adapter methods and their own tests —
+  four sites, all inside `@objectstack/service-storage`, all of them producers. REST, the
+  CLI, the storage routes, the attachment/file-reference lifecycles and the backfill
+  tooling never called `list` on either adapter, on the swappable proxy, or on the
+  `file-storage` service. #5172 came closest and walked away: it planned to reclaim email
+  attachments by listing `EMAIL_ATTACHMENT_KEY_PREFIX`, found the local adapter could not
+  see one level down, and switched to queue-driven deferred work instead.
+
+  **What the two implementations actually did**, which is why aligning them was rejected:
+
+  | Adapter               | Answered `list('a')` with                                                                                                                                                                                                      |
+  | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+  | `LocalStorageAdapter` | one level of `readdir` — a nested key `a/b/c` was invisible, you got `a/b` — and every subdirectory `stat` succeeded on was returned as if it were a file, so `size` was a directory inode and `download()` could not fetch it |
+  | `S3StorageAdapter`    | a recursive `ListObjectsV2` that read neither `IsTruncated` nor `ContinuationToken`, so past 1000 objects the "all files under this prefix" you got was the first page, indistinguishable from a complete answer               |
+
+  One contract method, two dialects, both silently incomplete, no signal on either.
+
+  **Migration.** Callers holding the contract type were already migrated by #5540 — the
+  member is gone from `IStorageService`, so `storage.list(...)` stops type-checking there.
+  This release also removes the method from the **concrete** classes, so a caller holding a
+  `LocalStorageAdapter` or `S3StorageAdapter` directly loses it too:
+
+  | Wrote                                                    | Write instead                                                                                                                                               |
+  | -------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |
+  | `new LocalStorageAdapter(...).list('attachments/task/')` | query the records you wrote — `sys_file` / file-reference rows carry the storage key and page deterministically through ObjectQL                            |
+  | `new S3StorageAdapter(...).list(prefix)`                 | same; for a genuine bucket sweep, call `ListObjectsV2` through the AWS SDK yourself and handle `ContinuationToken`, which is the part the adapter never did |
+  | a custom adapter of your own with `list?(prefix)`        | nothing breaks — an extra method on a class is not a type error; delete it whenever it suits you                                                            |
+
+  Querying your own records is not a workaround for the missing method. It is the only form
+  that was ever correct on both backends and past 1000 objects: the bucket was never the
+  system of record for "which files exist" — the rows are.
+
+  **If enumeration ever comes back, it comes back cursor-shaped.** Not this signature. A
+  prefix listing that cannot paginate is the wrong shape to inherit, so a future
+  first-party need returns `list(prefix, { cursor, limit })` — a page plus a continuation
+  token — with adapter-conformance cases (nested keys, directory entries, more than 1000
+  objects) proving both backends agree _before_ either ships. Maintainer ruling 2026-08-05
+  on #5266 chose this over aligning the two adapters, which would have grown a conformance
+  surface nobody walks.
+
+  Patch rather than major: the contract break was #5540's and shipped there. `tsc` cannot
+  see this one — a class may carry members its interface does not declare, which is exactly
+  why the #5540 changeset told adapter authors that leaving an implementation in place
+  still compiles — so the absence is held by a runtime pin,
+  `storage-adapter-list-retirement.test.ts`, instead.
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [64cd010]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [b746aa0]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [08f93bc]
+- Updated dependencies [d9971d3]
+- Updated dependencies [eb3e650]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [02dc076]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [e98fb14]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [1b9a53b]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [46365ab]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [c5adfe1]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [f104bab]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/types@17.0.0-rc.4
+  - @objectstack/core@17.0.0-rc.4
+  - @objectstack/platform-objects@17.0.0-rc.4
+  - @objectstack/observability@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Patch Changes
diff --git a/packages/services/service-storage/package.json b/packages/services/service-storage/package.json
index c742944581..2d13fd422f 100644
--- a/packages/services/service-storage/package.json
+++ b/packages/services/service-storage/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/service-storage",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "Storage Service for ObjectStack — implements IStorageService with local filesystem and S3 adapter skeleton",
   "type": "module",
diff --git a/packages/spec/CHANGELOG.md b/packages/spec/CHANGELOG.md
index 468eab8e87..b7bb5c7778 100644
--- a/packages/spec/CHANGELOG.md
+++ b/packages/spec/CHANGELOG.md
@@ -1,5 +1,5408 @@
 # @objectstack/spec
 
+## 17.0.0-rc.4
+
+### Major Changes
+
+- 29c6c9d: feat(spec,core,runtime)!: declarative `apis:` refuses loudly instead of parsing into silence; the `ApiRegistry` family retires (#4936, #4939)
+
+  The declarative API-endpoint surface was **zero-execution end to end**, and said nothing
+  about it. Metadata loading worked perfectly — a stack declared `apis:`, `defineStack`
+  accepted it, and `GET /api/v1/meta/api` returned every endpoint with every key intact.
+  The execution side never fired once. On a real boot (showcase, 47 plugins) both declared
+  paths answered a bare `404 {"error":"Not found"}` — not even the dispatcher's semantic
+  404, because **no route was ever mounted** for a declared path, so the request died at
+  Hono's `notFound`. Behind that, the dispatcher's `handleApiEndpoint` branch resolved the
+  metadata service and called `matchEndpoint` on it — a method **no implementation in the
+  repo has ever provided**. The branch returned "not handled" on every request ever served.
+
+  So every key on `ApiEndpointSchema` was declared ≠ enforced: `path`/`method` (never
+  mounted), `type`/`target`/`objectParams` (never executed), `cacheTtl`,
+  `inputMapping`/`outputMapping`, `rateLimit`, `summary`/`description` — and
+  **`authRequired`**, a security semantic that parsed green and gated nothing at all. That
+  is false compliance, the failure ADR-0049 exists to stop, not debt.
+
+  ## BREAKING — a non-empty `apis:` is now rejected
+
+  Metadata that parsed cleanly before is now **refused at publish/validate**, with the
+  prescription in the rejection itself:
+
+  ```
+  apis: `apis:` (declarative ApiEndpoint) is DECLARED BUT NOT EXECUTABLE in this runtime,
+  so a non-empty array is rejected instead of silently accepted (#4936). …
+  ```
+
+  **FROM → TO.** `apis: [ …endpoints… ]` → `apis: []` (or delete the key; both are still
+  accepted, and an empty array is not a special case). To actually serve the route today,
+  mount it **in code** — a plugin manifest `contributes.routes` entry, or an `http.server`
+  route. That is now the only honest path, and the one `examples/app-showcase` uses
+  (`src/system/server/recalc-endpoint.ts`).
+
+  The refusal lives on `ObjectStackDefinitionSchema` itself, which is the single choke
+  point every path runs through — `defineStack`, the metadata plugin's artifact ingestion,
+  `os validate`, the lint scorer and `EnvironmentArtifactSchema`. There is no path that
+  forgot to check.
+
+  **The `ApiEndpoint` vocabulary is deliberately KEPT.** Retiring it was considered and
+  rejected: endpoint shapes are an industry-stable form, so a retirement would only mean
+  re-introducing the identical schema later. Your endpoint definitions stay valid TypeScript
+  and stay in the spec; only _authoring them into a stack_ is refused, and only until the
+  executor lands. Keep them commented next to your stack — that is what the showcase does.
+  The executor (route mounting + endpoint matching + per-key wiring for
+  `authRequired`/`cacheTtl`/`inputMapping`/`outputMapping`/`rateLimit`) is tracked by
+  **#5040**, which replaces this rejection with real execution.
+
+  ## BREAKING — the `ApiRegistry` / `ApiEndpointRegistration` family is removed (#4939)
+
+  The repo carried a **second**, unrelated declaration shape for "an API endpoint":
+  `ApiEndpointRegistrationSchema` and the ~500-line `ApiRegistry` service that
+  `createApiRegistryPlugin()` registered under `api-registry`. Nothing composed it — every
+  assembly site lived in `packages/core/examples/`, with no registration in
+  `packages/runtime`, `packages/cli` or any `examples/app-*`, and a real boot carried no
+  such service. The whole family was therefore inert, including
+  `ApiEndpointRegistration.requiredPermissions`, whose docs promised **in the present tense**
+  that "the gateway layer automatically validates these permissions" while no gateway read
+  it. Two declaration shapes, both dead; this retirement converges them on one.
+
+  Removed from `@objectstack/spec/api`: `ApiEndpointRegistration(Schema)`,
+  `ApiRegistry(Schema)`, `ApiRegistryEntry(Schema)`, `ApiMetadataSchema`,
+  `ApiParameterSchema`, `ApiResponseSchema`, `ApiDiscoveryQuerySchema`,
+  `ApiDiscoveryResponseSchema`, `ApiProtocolType`, `HttpStatusCode`,
+  `ObjectQLReferenceSchema`, `SchemaDefinition` (12 JSON-Schema defs, 67 authorable keys).
+  Removed from `@objectstack/core`: `ApiRegistry`, `createApiRegistryPlugin`.
+  Removed from `@objectstack/plugin-hono-server`: the `useApiRegistry` option — it was
+  defaulted to `true` and read by nothing, configuring a service that was never composed.
+
+  **FROM → TO.** There is no replacement shape to migrate to, because nothing executed the
+  old one: delete the registration objects. If you were assembling an `ApiRegistryEntry`,
+  you were building a value only your own code read — keep it as your own type. Declarative
+  endpoints have one vocabulary now, `ApiEndpointSchema`.
+
+  `ConflictResolutionStrategy` **survives** the removal and moved to
+  `@objectstack/spec/api`'s `router.zod` — same name, same four values
+  (`error`/`priority`/`first-wins`/`last-wins`), same import path. It is pinned there by two
+  independent ratchets and is not part of the retired surface.
+
+  ## Also in this change
+
+  - **BREAKING (`@objectstack/runtime`):** `HttpDispatcher.handleApiEndpoint()` is deleted,
+    along with its now-orphaned private `callData` delegate, and `/__api-endpoint` leaves
+    `LEGACY_CHAIN_PREFIXES` and the route ledger. The method was public, so this is an API
+    removal — but it returned `{ handled: false }` for every call it ever received, so no
+    caller can observe a behaviour change beyond the missing symbol. Delete the call.
+    Absence is now loud (ADR-0076): the surface is refused at authoring rather than 404ing
+    at runtime with dead code behind it.
+  - `examples/app-showcase` no longer declares endpoints, and its coverage manifest no
+    longer claims the capability is `demonstrated` — that entry read "executed by the runtime
+    dispatcher (handleApiEndpoint)", which was exactly the advertise-what-you-don't-deliver
+    claim Prime Directive #10 forbids.
+  - The endpoint-level `rateLimit` tracking pointers left by #4910/#5006 now name **#5040**,
+    the live executor card, instead of #4936, which closes with this change.
+
+- d21c001: feat(spec)!: declarative `apis:` publishes again — the blanket refusal narrows to per-endpoint publish gates, and declared endpoints go LIVE (#5111, #5040 E7)
+
+  ⚠️ **Read this as a security note, not a schema note.** Declarative endpoints
+  **execute** from protocol 17. Before this release the surface was inert end to
+  end — nothing mounted a declared `path`, no matcher existed, and every key
+  including `authRequired` parsed green and gated nothing — which is why #4936
+  refused a non-empty `apis:` outright. The #5040 E-series built the executor
+  (mount seam, endpoint matcher, policy keys, execution targets, mapping keys,
+  OpenAPI enrichment), so the refusal's premise is gone and keeping it would be
+  the lie in the other direction.
+
+  ## BREAKING — the refusal narrows, and what passes it is served
+
+  `apis: [ …endpoints… ]` no longer fails wholesale. Each entry is now gated
+  individually, and **an endpoint that passes the gate is mounted and answers
+  real requests as soon as the stack is published.**
+
+  **Before you upgrade, review every historical `apis:` block** — including any
+  you restored, generated from an older doc, or left in place because it was
+  known to do nothing. Pay particular attention to any entry that explicitly
+  declares **`authRequired: false`**: the schema default is `true`, so an
+  _omission_ is safe and needs no review, while an explicit `false` is the only
+  thing that opens **anonymous** access to that endpoint. ADR-0121 D6 now pairs
+  it with a mandatory armed rate limit — and "armed" means
+  `rateLimit: { enabled: true, … }`, because `enabled` defaults to `false`, so a
+  budget written without it meters nothing.
+
+  ## The gates, each rejecting with its own prescription
+
+  | gate                           | rejected shape                                                                                                                                                                                                                                                                  |
+  | ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+  | **namespace** (ADR-0121 D1/D2) | a `path` that is not `/api/v1/apps/<manifest.namespace>/<subpath>`, or a stack that declares `apis:` without an explicit `manifest.namespace` (no derivation from `manifest.id`)                                                                                                |
+  | **supported subset**           | `type: 'script'` / `'proxy'`; an `object_operation` missing `objectParams.object` or `.operation`; a `flow` with an empty `target`                                                                                                                                              |
+  | **mapping**                    | any `transform`; an unusable `source`/`target` path (empty, empty segment `a..b`, `__proto__`/`prototype`/`constructor`); two entries whose `target`s collide (same path, or one inside another); `inputMapping` on a `find`/`get`/`delete` operation, which never reads a body |
+  | **policy**                     | `authRequired: false` without `rateLimit.enabled === true`; an armed budget with `maxRequests`/`windowMs` ≤ 0; a negative `cacheTtl`; `cacheTtl` on a non-GET method                                                                                                            |
+  | **uniqueness**                 | two endpoints in one stack claiming the same METHOD + path (one trailing slash trimmed, the matcher's own rule)                                                                                                                                                                 |
+
+  **FROM → TO.** `path: '/api/v1/<anything>/thing'` →
+  `path: '/api/v1/apps/<manifest.namespace>/thing'`, with `manifest.namespace`
+  declared explicitly. `authRequired: false` → either delete the key (the safe
+  default `true` applies) or keep it **and** add
+  `rateLimit: { enabled: true, windowMs: 60000, maxRequests: 100 }`. Every other
+  key is unchanged: the `ApiEndpoint` vocabulary is frozen — this release adds,
+  removes and renames nothing on it. The gates are validation logic over the keys
+  that already existed.
+
+  The runtime keeps its own refusals for a declaration that reached the store
+  without passing publish (a direct `metadata.register()`), so the two ends agree:
+  what publish accepts is exactly what the executor serves.
+
+  `normalizeEndpointPath` is now exported from `@objectstack/spec/api` and is the
+  one canonical form of a declared path — the publish gate and the endpoint
+  matcher (`@objectstack/metadata`) read the same rule instead of each carrying a
+  copy, so a stack can never publish a duplicate the matcher would silently
+  resolve to a single winner.
+
+- a019e52: fix(spec)!: `composeStacks` 不再静默丢弃顶层键 —— 同值放行、冲突报错、未声明规则必警 (#5005)
+
+  `composeStacks` 从一个空对象开始逐项填充:`manifest`、`i18n`、`objects`,再加一份
+  手工维护的数组白名单。**不在白名单里的顶层键不是"原样保留",而是被删除** ——
+  不报错、不告警,消费方看到的 `undefined` 与"作者从没写过"完全无法区分。
+
+  组合栈是平台的应用打包/安装承载,所以这份静默一路蔓延到了安全配置:
+
+  | 顶层键                                                                              | 谁消费                                  | 组合后(修复前)                  |
+  | :---------------------------------------------------------------------------------- | :-------------------------------------- | :------------------------------ |
+  | `api`(含 `enforceProjectMembership` 每环境成员 403 闸门)                            | `objectstack serve` → REST + dispatcher | **丢**                          |
+  | `server`(`security.rateLimit` / `trustProxy`,#4910)                                 | `objectstack serve` → 入站限流器        | **丢**                          |
+  | `functions`(声明式 hook / action / script 节点按名解析的 handler)                   | `AppPlugin` 启动绑定                    | **丢**                          |
+  | `datasourceMapping`、`datasets`、`jobs`、`emailTemplates`、`docs`、`books`、`tiers` | 各自运行时                              | **丢**(声明为数组,却漏进白名单) |
+  | `runtimeModule`                                                                     | 构建产物的 ESM handler bundle           | **丢**                          |
+
+  `stacks.length === 1` 时 `composeStacks` 原样返回,所以单栈一切正常 —— 只有真正
+  ≥2 个栈才丢,这是它至今没被发现的原因。ADR-0109 当年也只是给 `tools` 单独补了
+  一行白名单,并没有堵住这一类。
+
+  ## 新语义(维护者 2026-08-04 裁决)
+
+  1. **同值放行** —— 多个栈声明同一个非数组顶层键且值深相等,照常合成。
+  2. **冲突报错**,错误信息点名冲突键、两个来源栈(manifest id,无 manifest 时用
+     `stack #N`)与两条出路(改一致 / 只在应当拥有它的那个栈里保留)。
+     ⛔ **不做 last-wins** —— 后组合的包无声关掉前一个栈的 403 闸门或收紧过的限流
+     预算,正是本单要消灭的静默安全降级;⛔ **不做 deep-merge** —— 那会造出一个两
+     位作者都没写过的第三种值。
+  3. **未声明规则的顶层键必警** —— 按默认规则合成(数组拼接,其余按单值规则)**并**
+     点名告警指向 #5005,而不是消失。
+
+  数组键的拼接语义一字不变。`functions` 按名合并(组合 CRM + Todo 必须两边的
+  handler 都在),重名报错而非择一;两种书写形态(map / array)不互转(array 条目
+  带 `packageId`,map 条目没有位置放它),混用报错。`i18n` 保留既有 last-wins ——
+  它是这里唯一本来就有明确策略的键,本单主题是"被丢掉的键",不动它。
+
+  ## 结构性保证
+
+  顶层键的处置表类型是 `Record< keyof ObjectStackDefinition, ComposeDisposition >`,
+  **新增一个顶层键而没说清它怎么合成,`tsc --noEmit` 直接不过**。白名单让"忘记"成为
+  默认,处置表让它成为编译错误;运行时那条 warn 兜住类型看不见的入口
+  (`strict: false`、手搓 stack 对象)。
+
+  ## 破坏性
+
+  组合两个对 `api` / `server` / `runtimeModule` 声明了**不同**值的栈,过去静默丢弃、
+  现在抛错;`functions` 重名同理。这正是要的:过去"成功"的那次组合,产出的是一个
+  少了闸门或少了 handler 的栈。改法见错误信息里的处方。
+
+- 64fc6d5: refactor(spec)!: remove `connector.rateLimitConfig` and the whole outbound rate-limit shape — the engine never existed (#4911, ADR-0049)
+
+  `ConnectorSchema.rateLimitConfig` let an author declare an outbound throttle for
+  their connector — `strategy`, `maxRequests`, `windowSeconds`, `burstCapacity`,
+  `respectUpstreamLimits`, `rateLimitHeaders` — and nothing anywhere applied it.
+  This is not the ordinary declared-but-unread case; it is a step worse:
+  **there is no outbound rate-limiting engine to wire it to.** The only token
+  bucket the platform owns is `packages/runtime/src/security/rate-limit.ts`, and it
+  is INBOUND — the dispatcher calls `consume(key)` on a request fingerprint and
+  answers 429. No connector provider (`connector-rest`, `connector-openapi`,
+  `connector-mcp`, `connector-slack`) reads the key, and no seam exists that could.
+
+  So a well-formed, schema-validated block told the author they had capped their
+  call rate against a third party's quota, and capped nothing — the false-compliance
+  class ADR-0049 exists for. With no implementation and no committed roadmap,
+  `experimental` would be a promise nobody made; **absent** is the honest
+  disposition. The vocabulary comes back _with_ the engine, in one change
+  (implementation-first — the #4834 / PR #4878 ruling for the plugin-runtime family).
+
+  FROM → TO:
+
+  | Removed                                                       | Replacement                                                                  |
+  | :------------------------------------------------------------ | :--------------------------------------------------------------------------- |
+  | `connector.rateLimitConfig` (key)                             | **none** — delete it; throttle at the connector provider or upstream gateway |
+  | `ConnectorRateLimitConfigSchema` / `ConnectorRateLimitConfig` | **none** — importing either is TS2305 in v17                                 |
+  | `RateLimitStrategySchema` / `RateLimitStrategy`               | **none** — the enum had no other consumer                                    |
+
+  **Do NOT substitute `shared`'s `RateLimitConfig`.** That is the INBOUND limiter
+  (`enabled` / `windowMs` / `maxRequests`) and caps the calls others make to _us_ —
+  the opposite direction. #4684 split the two names for exactly this confusion; the
+  conversion deliberately does not rewrite one into the other, because that would
+  silently change behaviour rather than losing a no-op.
+
+  The retirement kit:
+
+  - **Tombstone.** `ConnectorSchema` is not `.strict()`, so a plain delete would be
+    a silent strip (ADR-0104). `retiredKey()` makes the removal audible in the two
+    channels an upgrading author hits — `tsc` (the key types `never`) and the parse
+    (the prescription itself). It reaches `stack.connectors[]` and
+    `DeclarativeConnectorEntry`, which is `ConnectorSchema.superRefine(…)`.
+  - **ADR-0087 D2 conversion + D3 chain step** (`connector-rate-limit-config-removed`,
+    `retiredFromLoadPath`): `os migrate meta --from 16` deletes the key from author
+    sources and stored rows replay clean. A lossless delete — the block never had an
+    effect to lose.
+  - **The shape goes with the key.** `ConnectorRateLimitConfigSchema` and the
+    `RateLimitStrategySchema` enum it embedded had no other consumer, and an
+    exported schema with no consumer reads as a capability to whoever finds it
+    (#3950).
+  - **#4684's rename is absorbed.** `integration/RateLimitConfig` →
+    `integration/ConnectorRateLimitConfig` and this retirement landed in the same
+    unreleased major; composed they are a plain delete, so the `RENAMED_DEFS` entry
+    is removed rather than pointing at a def this build no longer emits.
+  - Baselines updated deliberately: `json-schema.manifest.json` (−2 defs),
+    `authorable-surface.json` (−6 def lines; `Connector` /
+    `DeclarativeConnectorEntry` gain `… [RETIRED]`), `api-surface.json` (−4
+    exports). `api-surface-signatures.json` is unchanged by construction — it hashes
+    each `defineX` parameter as TypeScript _prints_ it, a reference
+    (`z.input<typeof ConnectorSchema >`), so key-level narrowing never reaches it.
+
+  No runtime behaviour changes — that impossibility is the reason for the removal.
+
+- eaaf03c: refactor(spec,lint)!: retire the dashboard widget action trio + `aria` — and the build gate that enforced a button nobody renders (#5010, ADR-0049)
+
+  `DashboardWidgetSchema` let an author declare a per-widget action **button**
+  (`actionUrl` / `actionType` / `actionIcon`) and per-widget ARIA attributes
+  (`aria`). None of the four reached a renderer. Re-measured 2026-08-04 across both
+  repos on a closed call graph:
+
+  - **the action trio** — all 14 `actionUrl` reads in objectui's
+    `DashboardRenderer.tsx` are scoped to `schema.header.actions[]`, which is
+    `DashboardHeaderAction`, a _different_ schema. Nothing anywhere reads
+    `widget.actionUrl`. `actionIcon` is the starkest: zero references in either
+    repo outside its own declaration — not even the lint looked at it.
+  - **`aria`** — no consumer of `widget.aria` anywhere. The `aria-*` attributes in
+    `DashboardRenderer` / `DatasetWidget` are the renderer's own DOM attributes,
+    and objectui's single `.aria` read (`plugin-view/ObjectView.tsx:989`) is a
+    **view**'s. This is the dashboard-level `aria` that #3896 removed, one level
+    down — an accessibility guarantee an author could declare and nothing honoured.
+
+  These four survived the #3896 sweep for the same reason `widgets[].responsive`
+  did, and it is not "we looked and they were live": the liveness ledger declared
+  no `children` on `dashboard.widgets`, so **no widget-level key had ever been
+  classified**. #4956 fixed that instrument and gave all 22 keys their first per-key
+  verdicts; this change acts on four of the six it found dead.
+
+  ## The second-order cost this settles
+
+  `packages/lint`'s `validate-dashboard-action-refs` enforced **ERROR-severity**
+  reference integrity on `widgets[].actionUrl` — a dangling target failed the
+  build. Its docblock called the key _"the per-widget button"_ and claimed to
+  mirror the objectui runtime dispatch. It did not, because that button does not
+  exist. So an author could be blocked from shipping because a control that cannot
+  render pointed at an action that also did not.
+
+  A rule written to delete false affordances was sustaining one. That is why the
+  keys were retired rather than the check merely relaxed: the widget branch is
+  deleted, with a pin test asserting it stays silent and a second pin proving
+  header actions are still checked in the same stack.
+
+  FROM → TO:
+
+  | Removed                          | Replacement                                                                                            |
+  | :------------------------------- | :----------------------------------------------------------------------------------------------------- |
+  | `dashboard.widgets[].actionUrl`  | `dashboard.header.actions[].actionUrl`                                                                 |
+  | `dashboard.widgets[].actionType` | `dashboard.header.actions[].actionType`                                                                |
+  | `dashboard.widgets[].actionIcon` | `dashboard.header.actions[].icon` (the header spelling)                                                |
+  | `dashboard.widgets[].aria`       | **none** — delete it; author `title`/`description`, which the renderer really does label the card with |
+
+  For a per-**row** affordance, reach for a dataset-bound `table`/`pivot` widget:
+  its rows are clickable and drill through the semantic layer already (no
+  per-widget drill config exists, by design — #5022).
+
+  **The `AriaProps` shape is NOT removed — only this embed.** `AriaPropsSchema` /
+  `AriaProps` stay exported and stay live on `app.aria` and
+  `page.components[].aria`. Nothing importing the shape breaks.
+
+  The retirement kit:
+
+  - **Tombstones.** `retiredKey()` on all four, matching `responsive` in this same
+    schema. `DashboardWidgetSchema` _is_ `.strict()`, so a plain delete would still
+    be loud — but only as a generic "unrecognized key". The tombstone keeps the key
+    declared so the rejection carries the **prescription**, and types it `never` so
+    authoring it fails `tsc` first. Pins assert the message _is_ the prescription
+    and is _not_ `Unrecognized key`. The action trio shares one prescription that
+    names all three, so an author who deletes the one key they were told about does
+    not hit the same error twice more.
+  - **ADR-0087 D2 conversion + D3 chain step**
+    (`dashboard-widget-action-aria-removed`, `retiredFromLoadPath`):
+    `os migrate meta --from 16` strips the four from author sources, and stored
+    dashboards replay clean instead of meeting a tombstone at load. Lossless
+    deletes — none of the keys had an effect to lose. Its own entry rather than
+    more keys on `dashboard-inert-keys-removed`, whose identity is the #3896 sweep.
+  - **Liveness rows stay** (`status: dead`, `verifiedAt`, a REMOVED note) because
+    a tombstone keeps the key in the walked shape — the `rls.priority` precedent.
+    `authorWarn`/`authorHint` are dropped from all four: the parse owns them now.
+  - Baselines moved at KEY level only, as the shape's survival implies:
+    `authorable-surface.json` gains four `… [RETIRED]` lines;
+    `json-schema.manifest.json`, `api-surface.json` and
+    `api-surface-signatures.json` are unchanged by construction — no def stopped
+    being emitted and no export was removed.
+
+  No runtime behaviour changes — that impossibility is the reason for the removal.
+  The one behaviour that _does_ change is a build that used to fail and now does
+  not.
+
+  ## Not in this change
+
+  `widgets[].colorVariant`, the fifth dead key #5010 lists, is **deliberately
+  untouched**. The rewrite target its triage assumed — `options.colorVariant` —
+  measured dead as well: `options` only reaches a renderer through the inline
+  `componentSchema` path, and `dataset` is _required_ on this schema, so every
+  spec-authorable widget is dataset-bound and renders through `DatasetWidget`,
+  which has no colour affordance at all. Moving the key would relocate 16 authored
+  sites (7 in `platform-objects`, 9 in `app-showcase`) from one dead slot to
+  another and mint a second inert key. Returned for adjudication.
+
+- d17df80: **BREAKING — `dashboard.widgets[].compareTo` converges on the analytics executor's contract (#5011).**
+
+  The widget declared three period-over-period arms with confident TSDoc. The analytics
+  executor implements one shape, and it was never the same one — so on the ADR-0021 dataset
+  path (the spec's own "single author-facing analytics shape") **all three arms were
+  broken**, in two different ways:
+
+  - `compareTo: 'previousPeriod'` / `'previousYear'` were **silently DROPPED** by the dataset
+    renderer. The widget rendered its base numbers and the comparison the author asked for
+    simply was not there.
+  - `compareTo: { offset: '7d' }` was forwarded into `DatasetSelection.compareTo`, whose
+    contract is `{ kind, dimension }` and has no `offset` in it — so the executor threw
+    `compareTo requires a timeDimension "undefined"` and the whole widget errored out.
+
+  All three worked on the legacy inline chart path. Same key, two fates, and the failing one
+  was the path the spec calls canonical.
+
+  `compareTo` is now a thin projection of the contract that is actually implemented:
+
+  ```ts
+  compareTo?: { kind: 'previousPeriod' | 'previousYear'; dimension?: string }
+  ```
+
+  There is no widget-side vocabulary left to drift from the executor's, so `declared =
+enforced` holds by construction rather than by review.
+
+  ## FROM → TO
+
+  | v16                                        | v17                                     | Fix                                                                                                                                   |
+  | :----------------------------------------- | :-------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------ |
+  | `compareTo: 'previousPeriod'`              | `compareTo: { kind: 'previousPeriod' }` | `os migrate meta --from 16` rewrites it                                                                                               |
+  | `compareTo: 'previousYear'`                | `compareTo: { kind: 'previousYear' }`   | `os migrate meta --from 16` rewrites it                                                                                               |
+  | `compareTo: { offset: '1y' }`              | `compareTo: { kind: 'previousYear' }`   | `os migrate meta --from 16` rewrites it — `1y` **is** `previousYear`                                                                  |
+  | `compareTo: { offset: '7d' \| '1M' \| … }` | **no faithful target**                  | State the window on the widget's own `filter` and compare with `{ kind: 'previousPeriod' }`, which shifts by that window's own length |
+
+  The last row is deliberately _not_ rewritten. `previousPeriod` shifts by the length of
+  whatever window the filter resolves to, which equals `7d` only when that window happens to
+  be seven days — a mechanical rewrite would silently change which rows the comparison
+  column counts, turning a loud failure into a wrong number. It is registered as the
+  `dashboard-widget-compareto-offset` semantic migration; the schema rejects the key with the
+  prescription in hand.
+
+  Retired at the schema, so every old spelling is a parse error carrying its own upgrade —
+  including the bare strings, which are dispatched by value so a _typo_ is still told it is a
+  typo rather than told it "was removed".
+
+  ## `dimension` is optional — resolved by the executor, not by a renderer
+
+  Omit it and `dataset-executor.ts` resolves it, by its own long-standing criterion (a
+  `timeDimensions` entry carrying a `dateRange`):
+
+  - exactly one candidate → that one is shifted;
+  - **zero** → a loud error: a comparison is only defined against a bounded window;
+  - **two or more** → a loud error **listing the candidates by name**, never a silent
+    first-wins. Picking `created_at` when the author meant `close_date` produces a comparison
+    that is _wrong_ rather than _missing_, which is the failure nobody audits.
+
+  This is a producer-side resolution rule, not consumer-side tolerance (Prime Directive
+  #12): every caller — dashboard widget, report, raw `queryDataset` — gets the same dimension
+  or the same error, and no renderer is ever in a position to guess one.
+
+  ## Notes
+
+  - `DatasetCompareTo.dimension` is now optional. Callers that always passed it are
+    unaffected; callers that relied on the old "must be present" typing get a wider type.
+  - The converged slot is **union-free**. That is not cosmetic: zod collapses a failed union
+    into one bare `Invalid input`, so curated guidance written inside a union arm never
+    reaches the author (#5014). This slot's prescriptions are top-level and do.
+  - objectui's legacy inline chart path adapts separately (objectui#3337), which also deletes
+    the `DatasetWidget` string-drop workaround this change makes unnecessary.
+
+- 7d0e7b5: refactor(spec)!: retire `dashboard.widgets[].responsive` — the straggler of the #3896 inert-key sweep (#4876, ADR-0049)
+
+  `DashboardWidgetSchema.responsive` let an author declare per-breakpoint layout
+  overrides on a dashboard widget — `breakpoint`, `hiddenOn`, `columns`, `order` —
+  and no renderer ever read them. The value parsed, validated, and then did
+  nothing: `DashboardRenderer`, `DashboardEditor` and `plugin-designer` name
+  `responsive` only in comments, and the one genuine per-breakpoint consumer in
+  objectui (`useResponsiveConfig`) is fed by `page.components[].responsive`, never
+  by a widget. Re-measured 2026-08-03 across both repos, plus zero authored
+  instances anywhere in this repo's examples, apps and tests.
+
+  Four days earlier, #3896 retired the **literally same-named** `view.responsive`
+  on exactly this evidence. This embed survived that sweep for a reason that is
+  worth stating plainly, because it is not "we looked and it was live": the
+  liveness ledger declares no `children` on `dashboard.widgets`, and the walk
+  drills only one level through an explicit `children` — so **no widget-level key
+  has ever been classified at all** (22 of them). The instrument had a hole, not
+  the key a mandate. That gap is filed and fixed separately as **#4956**.
+
+  Leaving it would have shipped v17 with one word and two fates — `view.responsive`
+  a `tsc` error, `dashboard.widgets[].responsive` silently accepted — which no
+  author or authoring agent could be expected to explain, on a key that today
+  accepts _any_ content on both sides (objectui types it a documented `any`). That
+  is precisely where AI-authored metadata errors hide and multiply.
+
+  FROM → TO:
+
+  | Removed                                | Replacement                                                                                                      |
+  | :------------------------------------- | :--------------------------------------------------------------------------------------------------------------- |
+  | `dashboard.widgets[].responsive` (key) | **none** — delete it; the grid reflows by `columns` + `gap` on the dashboard and the `layout` box on each widget |
+
+  **The shape is NOT removed — only this embed.** `ResponsiveConfigSchema` /
+  `ResponsiveConfig` stay exported and stay live on `page.components[].responsive`,
+  whose renderer genuinely reads them. Nothing that imports the shape breaks, and
+  an author who needs breakpoint behaviour today has a real place to put it. This
+  narrowness is deliberate: the maintainer's ruling covers the dashboard widget
+  surface only.
+
+  The retirement kit:
+
+  - **Tombstone.** `retiredKey()` on the widget key. `DashboardWidgetSchema` _is_
+    `.strict()`, so a plain delete would still be loud — but only as a generic
+    "unrecognized key". The tombstone keeps the key declared so the rejection
+    carries the **prescription**, and types the key `never` so authoring it fails
+    `tsc` first. A pin asserts the message is the prescription and _not_
+    `Unrecognized key`.
+  - **ADR-0087 D2 conversion + D3 chain step**
+    (`dashboard-widget-responsive-removed`, `retiredFromLoadPath`):
+    `os migrate meta --from 16` deletes the key from author sources, and stored
+    dashboards replay clean instead of meeting the tombstone at load. A lossless
+    delete — the key never had an effect to lose. Kept as its own entry rather than
+    folded into `dashboard-inert-keys-removed`, whose identity is the #3896 sweep:
+    this removal rests on its own 2026-08-03 measurement and should say so in
+    `spec-changes.json` and the upgrade guide.
+  - **No liveness row is added**, matching `widgets[].performance` in the #3896
+    sweep — a widget-level row would be an ORPHAN, not a classification, until
+    #4956 lands the drill. The ledger `_note` records the removal and why the row
+    is absent.
+  - Baselines moved at KEY level only, as the shape's survival implies:
+    `authorable-surface.json` gains `ui/DashboardWidget:responsive [RETIRED]`;
+    `json-schema.manifest.json`, `api-surface.json` and
+    `api-surface-signatures.json` are unchanged by construction — no def stopped
+    being emitted and no export was removed.
+
+  No runtime behaviour changes — that impossibility is the reason for the removal.
+
+  **objectui shard:** the outcome is retirement, not the fallback clause, so
+  objectui#3235's conditional pin-bump item is permanently de-listed; the `any`
+  declaration on that repo's side can be cleaned on its own schedule.
+
+- 6513c17: refactor(spec)!: `IDataDriver` 的 query 参数改为 `DriverQuery`（`Omit<QueryAST, 'object'>`），对象名只写一遍 (#5181)
+
+  `IDataDriver.find/findOne/count/updateMany/deleteMany/explain` 的第一个实参已经是对象名，而它们要求的 `QueryAST` 又把 `object` 列为必填 —— 同一个事实被要求写两遍，并因此有了两处互相矛盾的余地。上层为这份歧义已经付过账：objectql 引擎刻意把键序写成 `{ ...query, object }`，好让一个夹带的 `query.object` 覆盖不掉已解析的名字；wire 层则用一条具名 400（`QUERY_OBJECT_MISMATCH`）拒绝不一致。
+
+  驱动这一侧付的账是**成片的 cast**：一个手上只有 `where` 的直接调用方叫不出这个类型的名字，于是 `as any`，连带把 `where`/`orderBy`/`fields` 的类型检查一起关掉（cloud#1053 实测 20 处；cloud#1030 的 `$like` 就是从这个口子活到运行时的）。
+
+  **FROM → TO**
+
+  ```ts
+  // FROM —— 对象名写两遍
+  await driver.find("account", {
+    object: "account",
+    where: { status: "open" },
+  });
+  // TO —— 第一个实参就是对象名
+  await driver.find("account", { where: { status: "open" } });
+  ```
+
+  一行修复：**删掉驱动调用字面量里的 `object:` 键**。编译器会把每一处指出来（TS2353 `'object' does not exist in type 'DriverQuery'`）。
+
+  **两个方向的兼容性，都不强迫任何一侧动**
+
+  - **调用方**：手上是一个 `QueryAST` **值**的，原样传即可 —— 它具备 `DriverQuery` 要求的全部属性，多出来的那个在非新鲜字面量上 TypeScript 一律接受。新被拒绝的**恰好只是冗余本身**：写在调用点上、拼出 `object` 的内联字面量。本仓的迁移面因此实测只有 1 个文件 6 处（`@objectstack/metadata` 的 history-cleanup），已在同一 PR 里删除；引擎的 `driver.find(object, ast, …)` 一个字都不用改。
+  - **驱动实现**：仍旧声明 `query: QueryAST` 的实现继续编译 —— 方法参数按双变比较。它们不再可以做的是**读 `query.object`**：调用方现在有权省略，声明会对一个运行时为 `undefined` 的值说谎。本仓五个驱动（memory / mongodb / sql / sqlite-wasm / turso）实测没有一个读它，因此本次不动驱动代码；把驱动签名一并迁到 `DriverQuery` 是后续的机械收尾。
+
+  `QueryAST` 的 zod 形状（`data/query.zod.ts` 的 `BaseQuerySchema`）**没有动**：`object` 在引擎与 hook 那一层是被读的，改的只是驱动契约的参数类型。`expand` 条目里的 `object` 同样保留 —— 那里它命名的是**关联对象**，没有任何实参携带这个事实，不是冗余。
+
+  标 major 是因为这是**源码级破坏性**变更（调用点字面量），运行时行为零变化。注意 `check:api-surface` 只看得见新增的 `DriverQuery` 导出、看不见参数类型的收窄（它记录导出存在与否，不记录签名），所以这条迁移说明是该变更唯一的下游载体。
+
+- 4dfd002: **`automation/etl.zod.ts`'s nine type aliases now follow the house `X` / `XParsed`
+  convention** (#4963): the bare name is `z.input` — what an author writes — and a new
+  `XParsed` is `z.infer` — what a parse returns.
+
+  Until 17 all nine were `z.infer` under the bare name with no `*Parsed` counterpart at
+  all. On this file that was not a style detail. Five named keys carry `.default()`
+  (`ETLDestination.writeMode`, `ETLTransformation.continueOnError`, `ETLPipeline.syncMode`
+  / `.enabled`, `ETLSource.incremental.enabled`), as does every key of
+  `ETLPipeline.retry` and of `ETLPipelineRun.stats`, and `schedule` is a
+  `CronExpressionInputSchema` transform whose _output_ is the `{ dialect, source }`
+  envelope. Under `z.infer` all of them were REQUIRED and a bare cron string was rejected — so the single use this file has, `const p: ETLPipeline = { … }`
+  written by hand, did not compile. That is the whole authoring door: `etl.zod.ts` has no
+  parse site in objectstack / objectui / cloud, so the exported schema and the exported
+  type are the only surface an author touches.
+
+  The evidence was checked in. `packages/spec/docs/SYNC_ARCHITECTURE.md` carried three
+  `ETLPipeline` examples, none of which compiled, and both `ETL` factories were spelling
+  out defaults and pre-wrapping their cron purely to satisfy their own return type.
+
+  ### Migration
+
+  **Zero importers across objectstack, objectui and cloud** (re-measured against each
+  repo's `origin/main` for this change), so the migration surface is empty. If you have a
+  local consumer:
+
+  | You wrote                                                             | Keep it if                           | Change it to                                 |
+  | :-------------------------------------------------------------------- | :----------------------------------- | :------------------------------------------- |
+  | `const p: ETLPipeline = { … }`                                        | you are AUTHORING a pipeline literal | nothing — this is the case that now compiles |
+  | `const p: ETLPipeline = ETLPipelineSchema.parse(raw)`                 | —                                    | `const p: ETLPipelineParsed = …`             |
+  | `function run(p: ETLPipeline)` reading `p.syncMode` as always-present | —                                    | `ETLPipelineParsed`                          |
+
+  The same rename applies to each of the nine: `ETLEndpointType`, `ETLSource`,
+  `ETLDestination`, `ETLTransformationType`, `ETLTransformation`, `ETLSyncMode`,
+  `ETLPipeline`, `ETLRunStatus`, `ETLPipelineRun` — append `Parsed` wherever the annotated
+  value came out of a `.parse()`. The four enum aliases are unaffected in practice
+  (`z.input` and `z.infer` coincide for an enum); their pair exists so a reader never has
+  to know which of the nine has defaults before choosing an annotation.
+
+  Nothing at runtime moves: no schema, default, bound or key changed, and both `ETL`
+  factories still produce documents that parse to the same result. `ETL.databaseSync` /
+  `ETL.apiToDatabase` no longer restate `enabled: true` and no longer pre-wrap a bare cron
+  string into `{ dialect: 'cron', source }` — the schema does that at parse, which is where
+  it always belonged. Each helper still states what it DECIDES (`incremental` + `upsert`
+  vs `full` + `append`), because that contrast is the reason the pair exists.
+
+  `SYNC_ARCHITECTURE.md`'s three examples now compile, and a compiler-API test
+  (`etl-author-shape.test.ts`) compiles them verbatim on every run — import line included —
+  so they cannot rot again silently.
+
+- 811c30c: 按 ADR-0049 enforce-or-remove 退役字段映射的 `transform` 键与整个 `FieldMappingTransform` 联合(#5552)
+
+  `shared/FieldMappingSchema.transform` 由一个五成员判别联合承载(`constant` / `cast` /
+  `lookup` / `javascript` / `map`),并被两个 `.extend()` 它的 schema 继承 ——
+  `integration/ConnectorFieldMapping` 与 `data/ExternalFieldMapping`。**五个成员没有一个
+  存在执行者**:`fieldMappings` 只在 `packages/spec` 自己的 schema 和测试里被拼写过,四个
+  connector 包、automation engine、REST 与 objectui 都不读它,全仓也没有任何代码对
+  `transform.type` 分支。这是完整意义上的 declared-but-unenforced(Prime Directive #10),
+  不只是报单所指的那一个成员。
+
+  `javascript` 成员是让缺口显形的那一个:它的 `.describe()` 推荐 `dialect: "js"`,而 `js`
+  方言早在 #3278(ADR-0058 addendum)就退役了 —— 于是文档教的信封写法被枚举直接拒收,唯一
+  能通过 parse 的裸字符串又被 `ExpressionInputSchema` 包成 `dialect: 'cel'`,而同一行给出的
+  例子 `value.toUpperCase()` 作为 CEL 并不成立。三处互相打架,且三处底下都没有实现。
+
+  ## FROM → TO
+
+  | 你现在写的                                                                     | 改成     |
+  | :----------------------------------------------------------------------------- | :------- |
+  | `connector.fieldMappings[].transform: { type: 'cast', targetType: 'string' }`  | 删除该键 |
+  | `connector.fieldMappings[].transform: { type: 'javascript', expression: '…' }` | 删除该键 |
+  | `externalLookup.fieldMappings[].transform: { … }`                              | 删除该键 |
+
+  **一句话修复:删掉 `transform` 键。** 没有等价替换成员 —— L3 connector 的字段映射只做
+  `source` → `target` 的搬运,从来没有做过值变换。真正要做值变换的地方有两个,都是活的:
+
+  - **导入映射** `mapping.fieldMapping[].transform` —— 一个扁平字符串枚举
+    (`none`/`constant`/`map`/`split`/`join`/`lookup`,配置放在 `params`),由 REST 导入
+    路径逐行执行。注意它对自己的 `javascript` 值是**直接 400 拒收**(服务端没有沙箱),
+    而不是解析通过然后什么都不做。
+  - **ETL transformation 步骤**,面向多源、多阶段的复杂变换。
+
+  存量元数据无需手改:`os migrate meta --from 16` 会自动重写(ADR-0087 D2 conversion
+  `field-mapping-transform-removed`);`sys_metadata` 里的存量行在 rehydration 时由
+  `applyConversionsToStoredItem` 重放同一条转换。直接 parse 会命中 `retiredKey()` 墓碑,
+  错误信息本身就是上面这段处方。
+
+  ## 退役套件
+
+  - **Schema**:`shared/mapping.zod.ts` 上 `transform` 改为 `retiredKey()` 墓碑(该 schema
+    与两个 extender 都是普通 `z.object`,直接删键会被静默 strip —— 用另一个静默 no-op 替换
+    原来的静默 no-op);`FieldMappingTransformSchema` / `FieldMappingTransform` 两个导出随键
+    一起删除(无其他消费者的值 schema 会被后来者读成一项能力,#3950)。
+  - **D2 conversion**:`field-mapping-transform-removed`,`toMajor: 17`,
+    `retiredFromLoadPath: true`,重写 `connectors[].fieldMappings[]`。
+  - **D3 chain step**:接入 `MIGRATIONS_BY_MAJOR[17].conversionIds` 并扩写 rationale。
+  - **退役登记**:`RETIRED_KEYS_BY_MAJOR[17]` 收三个键(一个墓碑 → 三处可作者化拼写,因为
+    两个 extender 各自复制了该属性);`RETIRED_DEFS_BY_MAJOR[17]` 收
+    `shared/FieldMappingTransform`。这是自 #4659 / #4725 建表以来两张表的首批条目。
+  - **生成物**:`authorable-surface.json` 三行转 `[RETIRED]`;`api-surface.json` −2;
+    `json-schema.manifest.json` −1 def;spec-changes / upgrade-guide / references 重生成。
+
+  **未受影响**:`ExpressionDialect` 本体、`ExternalLookup.transform`(lookup 级
+  request/response 管线,与字段映射无关)、以及上面那个活着的导入映射 `transform`。
+
+- abeb375: fix(spec)!: `HierarchyScopeContext.organizationId` is the authoritative tenancy field, and it is now required (#5858)
+
+  `HierarchyScopeContext` declared `organizationId?: string | null` and
+  `tenantId?: string | null` side by side with no doc saying which one carries the
+  caller's active organization. That silence had a measured cost (#5852): the
+  single in-repo producer (`@objectstack/plugin-sharing`) filled `organizationId`
+  from a `SharingExecutionContext` whose only tenancy member is `tenantId`, so the
+  read was structurally always `null`, while the real consumer — the enterprise
+  `hierarchy-scope-resolver` — reads `organizationId`, saw `null`, and skipped
+  tenant isolation. Both ends were individually contract-compliant; the pair was a
+  reachable cross-organization read.
+
+  The contract now says which field is authoritative, and enforces it structurally
+  rather than in prose:
+
+  - **`organizationId` is the authority** — the caller's active organization,
+    `null` = platform/unscoped, the same meaning `EvalUser.organizationId`
+    already carries. This is the repo's settled name for the concept, not a new
+    one: #3280 blessed `organizationId` as the developer-facing name for the
+    caller's active org (matching the `organization_id` column and
+    `current_user.organizationId` in RLS), #3290 removed the `session.tenantId`
+    alias in v11, and `scripts/check-org-identifier.mjs` gates it in CI.
+  - **It is REQUIRED** — `organizationId: string | null`, never omitted. A
+    producer that forgets to state the caller's org now fails to compile instead
+    of handing every resolver an `undefined` it will read as "unscoped". Stating
+    "no org" is still allowed, but it must be stated: `null` is a value, not an
+    omission.
+  - **`tenantId` is retained as a deprecated alias**, not removed. It stays the
+    generic driver-layer tenancy knob (a database-per-tenant kernel legitimately
+    puts an _environment_ id there), and its doc now says a resolver must not
+    depend on it alone or use it as a stand-in for a `null` `organizationId`.
+    Its removal is a separate, deliberate retirement.
+  - **`IHierarchyScopeResolver.resolveOwnerIds` documents the fail-closed
+    obligation**: when `organizationId` is `null`, an implementation must not
+    build the owner set as though no tenancy constraint applied — "no org" is
+    never "every org". Return owner-only (or throw, which the sharing layer
+    treats the same way); never widen.
+
+  **Migration.** Breaking for _producers_ of the context only — implementers of
+  `IHierarchyScopeResolver` are unaffected (a required property is strictly easier
+  to consume). A producer that omitted the key adds `organizationId: <the caller's
+active org, or null>`; a producer that was passing the org under `tenantId` must
+  move it, which is the bug this closes rather than a rename to absorb. The only
+  in-repo producer already supplied the key, so nothing in this repo changed
+  shape.
+
+- cbb6a5c: refactor(spec)!: retire `HookContext.session.roles` — declared, read by two dead branches, never produced (#5050)
+
+  `session.roles` on the runtime hook context was ADR-0049's enforce-or-remove
+  case with **neither end**: it was declared in `data/hook.zod.ts`, read by
+  exactly two consumers, and produced by nobody. The two readers were
+  plugin-approvals' admin exemptions — the approval record lock and the delegation
+  write guard, each opening with `session.roles?.includes('admin')` — and both
+  were deleted in #4839 (PR #5049) on the maintainer's ruling. The producer side
+  was empty the whole time: ObjectQL's `buildSession()` builds the session field
+  by field (`userId`, `organizationId`, `accessToken`, `isSystem`, `actor`, the
+  skip flags) and has never written `roles`, and nothing else feeds a
+  HookContext. So every read resolved `undefined`,
+  and a guard keyed on it was dead code that merely LOOKED like an authorization
+  decision — plus a second admin dialect competing with the one ADR-0090 D3 /
+  ADR-0095 D3 sanction.
+
+  Cross-repo consumer check ran in both directions before removing anything
+  (#4895's discipline, after #4865's tombstone was disproven by objectui):
+  `cloud` has zero `session.roles` while its hook consumers really do read
+  `hookContext?.session?.userId` (`service-cloud/src/marketplace-visibility-plugin.ts`,
+  `control-plane-org-scope-plugin.ts`) — a positive control in the same run;
+  `objectui` has zero, and its `roles` are the `/auth/me` **user** payload, a
+  different surface that is untouched.
+
+  One neighbour is called out rather than folded in, because mistaking it for a
+  producer would read as refuting the whole finding (#4865's lesson): an **action**
+  body's `ctx.session` is a different, untyped object built by `runtime`'s
+  `buildActionSession()`, and it does populate a `roles` key from `ec.positions`.
+  It never becomes a HookContext and no schema types it, so it is neither evidence
+  against this retirement nor fixed by it — it is filed and tracked apart.
+
+  **Nothing observable changes.** A key nobody wrote and nothing read cannot alter
+  a single decision — this is the declaration catching up with the runtime, not a
+  behaviour change.
+
+  FROM → TO:
+
+  - `HookContext.session.roles` (`@objectstack/spec/data`) → removed. Delete the
+    key. To gate a hook on the caller, read `ctx.session.userId` /
+    `ctx.session.isSystem`; to judge PRIVILEGE, ask the security service, which
+    evaluates capability grants (`permissions`), placements (`positions`) and the
+    derived posture off the execution context (ADR-0095 D3) — never a role-name
+    string comparison.
+
+  The retirement kit: the key is **tombstoned**, not deleted, because
+  `HookContextSchema` is deliberately not `.strict()` (strictness there would turn
+  an engine-internal enrichment into a breaking change for anyone parsing a
+  context they were handed, as `provenance` was in #3712) — a plain delete would
+  have stripped it in silence, the #3733 / ADR-0104 failure. `retiredKey()` gives
+  both channels instead: `tsc` types the key `never` at any producer, and a parse
+  raises the prescription itself. There is **no** ADR-0087 D2 conversion and
+  nothing for `os migrate meta` to rewrite: a HookContext is built per operation
+  by the engine and never stored, so no `sys_metadata` row, example or template
+  can carry the key — the `openApi31` (#4579) / `activationEvents` (#4657) shape,
+  registered as the `hook-context-session-roles-retired` **semantic** migration at
+  major 17 so the prescription still reaches `spec-changes.json`, the generated
+  upgrade guide and the `spec_changes` MCP tool. The four export/def ratchets are
+  unchanged by design: this narrows a nested key inside a surviving def, which
+  `api-surface.json`, `authorable-surface.json` (whose walk records top-level keys
+  per def), `api-surface-signatures.json` and `json-schema.manifest.json` are all
+  blind to — the enum-narrowing reading of the two, not the whole-def one.
+
+- 795b6e1: BREAKING(spec): `@objectstack/spec/shared` 与 `/ui` 改名 `HttpMethodSchema` → `HttpMethodSubsetSchema`、`HttpMethodType` → `HttpMethodSubset`;裸名 `HttpMethod(.json)` 现在全包唯一地指 7 值的路由契约,`HEAD`/`OPTIONS` 回到发布出去的 JSON Schema 与参考页 (#5832)
+
+  `packages/spec/src/shared/http.zod.ts` 在同一个文件里声明了两个**内容不同**的枚举,
+  而它们经 `schemaNameFromExportKey()` 剥掉 `Schema` 后缀后同名:
+
+  | 导出名             | 值域                          | 剥后的发布名 |
+  | :----------------- | :---------------------------- | :----------- |
+  | `HttpMethod`       | **7 值**(含 `HEAD`/`OPTIONS`) | `HttpMethod` |
+  | `HttpMethodSchema` | 5 值(view 数据源子集)         | `HttpMethod` |
+
+  `build-schemas.ts` 对 `generatedSchemas.set(defKey, …)` 是无条件覆盖,后写覆盖前写,
+  5 值那份按导出枚举顺序排在后面。实测结果:`json-schema/shared/HttpMethod.json`、
+  bundled `objectstack.json` 的 `$defs['shared/HttpMethod']`、以及
+  `content/docs/references/shared/http#httpmethod` **只描述 5 值那份** —— 而 7 值那份才是
+  `api/discovery`、`api/endpoint`、`api/plugin-rest-api`、`api/rest-server`、`api/router`
+  声明 `method` 字段用的线上契约。任何按发布出去的 JSON Schema 做校验的下游(IDE 自动补全、
+  codegen、AI 元数据作者)拿到的都是被截断的那一份,会以为 `HEAD`/`OPTIONS` 非法。
+  属于 AGENTS.md「Machine-readable surfaces must not lie」。
+
+  ## 发布面变化
+
+  - `shared/HttpMethod.json` 的 `enum` 从 5 值 **修正为** 7 值
+    (`GET`/`POST`/`PUT`/`DELETE`/`PATCH`/`HEAD`/`OPTIONS`)。这是**修复性契约变化**:
+    7 值那份一直是源码里 `api/*` 实际使用的那一个,只是从未被发布出去。
+  - 新增发布名 `shared/HttpMethodSubset`(5 值)。
+  - `ui/HttpMethod`(5 值)**改名**为 `ui/HttpMethodSubset`,登记在
+    `scripts/lib/renamed-defs.ts`。
+
+  ## 迁移
+
+  ```ts
+  // 5 值子集(view 数据源;`HttpRequestSchema.method` 校验用的就是它)
+  - import { HttpMethodSchema } from '@objectstack/spec/shared'; // 或 '/ui'
+  + import { HttpMethodSubsetSchema } from '@objectstack/spec/shared'; // 或 '/ui'
+  - import type { HttpMethodType } from '@objectstack/spec/ui';
+  + import type { HttpMethodSubset } from '@objectstack/spec/ui';
+  ```
+
+  ⚠️ **不要把 `HttpMethodSchema` 直接换成 `HttpMethod`。** `shared/HttpMethod` 是 7 值的那一个,
+  换过去会把类型悄悄放宽两个值,而 `HttpRequestSchema.method` 运行时仍只接受 5 值 ——
+  `method: 'HEAD'` 会通过编译、在 `.parse()` 抛错。这正是 #4691 当初拒绝合并两个名字的理由,
+  本次只是把当年留下的 `HttpMethodType` 这个「因为 `HttpMethod` 被占用才起的名字」换成了
+  说明其含义的名字,让发布名、schema const、类型别名三者按本包
+  `<Name>Schema` / `<Name>` 的惯例对齐(ADR-0112 D9:一个名字只指一件事;改名走 #4684
+  `RateLimitConfig` 的先例)。运行时值域**一字未动**。
+
+  ## 守卫
+
+  `build-schemas.ts` 补上「同一个 def key 被两个**不同** schema 写第二次 = 硬报错」
+  (`scripts/lib/def-key-collisions.ts`),在两个 ratchet 之前跑 —— 它们都以 def key 计量,
+  碰撞只产生一个 key,谁也看不见。`export const X = XSchema` 这种自别名(本包 `api`/`system`/`ui`
+  共 14 处)不算碰撞:两次写的是同一个对象,不可能改变发布出去的内容。
+
+- 175d789: refactor(spec)!: retire `HttpServerConfigSchema` — nine documented keys with zero readers AND no way to write them (#4938)
+
+  `system/http-server.zod.ts` declared `HttpServerConfigSchema` with nine keys —
+  `port`, `host`, `cors`, `requestTimeout`, `bodyLimit`, `compression`,
+  `security`, `static`, `trustProxy`. `authorable-surface.json` listed all nine
+  and `content/docs/references/` rendered them as protocol documentation. Both
+  halves of the contract were empty:
+
+  - **Zero runtime readers.** No package in any repo (objectstack / cloud /
+    objectui) ever parsed a document with this schema or read a key off it. The
+    only non-spec mentions were "Used by:" comments in `shared/http.zod.ts`
+    pointing back at it.
+  - **Zero authoring entry** — worse than the ordinary declared-but-unread
+    defect. `stack.zod.ts` had no `server:` key, `config-schema.json` had no
+    `HttpServerConfig`, and no settings manifest carried it, so the configuration
+    the docs promised could not even be written down, let alone take effect.
+
+  What actually decides these things is three _other_ shapes: the CLI `serve`
+  arguments, the Hono adapter's `ObjectStackHonoOptions`, and
+  `DispatcherPluginConfig.securityHeaders`. `HttpServerConfigSchema` was
+  unacquainted with all three. Per ADR-0049 enforce-or-remove, and the 2026-08-04
+  ruling on #4938, the unreachable face is removed.
+
+  FROM → TO, per retired key:
+
+  | removed                                                           | what to do instead                                                                   |
+  | ----------------------------------------------------------------- | ------------------------------------------------------------------------------------ |
+  | `HttpServerConfig.port` / `.host`                                 | the deployment owns the socket — `objectstack serve -p <port>` / `PORT`              |
+  | `HttpServerConfig.static`                                         | the transport plugin's `staticMounts`                                                |
+  | `HttpServerConfig.cors`                                           | the transport adapter — `OS_CORS_ORIGIN` / `OS_CORS_CREDENTIALS` / `OS_CORS_MAX_AGE` |
+  | `HttpServerConfig.security.helmet`                                | the dispatcher plugin's `securityHeaders` (on by default)                            |
+  | `HttpServerConfig.security.rateLimit`                             | `defineStack({ server: { security: { rateLimit } } })` — LIVE since #5006            |
+  | `HttpServerConfig.trustProxy`                                     | `defineStack({ server: { trustProxy } })` — LIVE since #5006                         |
+  | `HttpServerConfig.requestTimeout` / `.bodyLimit` / `.compression` | nothing consumes them; they return with an executor or not at all                    |
+
+  Two of the nine were **activated** rather than lost: #5006 mounted
+  `security.rateLimit` and `trustProxy` on the deliberately narrow
+  `StackServerConfigSchema`, which grows one key at a time, each arriving with its
+  consumer. `cors` is registered as the FIRST per-key admission candidate for that
+  shape — embedding (`example-embed-objectql`) is a real scenario — and will
+  arrive the #4910 way, key and executor together, rather than sitting on the
+  export surface as a dead declaration in the meantime.
+
+  The retirement kit:
+
+  - **No `retiredKey()` tombstone, deliberately** — route 3 of the retirement
+    playbook ("nothing parses it"), the shape #4834 / PR #4878 used for the kernel
+    plugin-runtime family. A tombstone is a message to whoever writes the key, and
+    the only surface on which anyone can write a server key is
+    `StackServerConfigSchema`; it is `strictObject` and already rejects all seven
+    by name. Those prescriptions were refreshed from "not authorable — no runtime
+    reads it" to name the retirement and its replacement.
+  - **No ADR-0087 D2 conversion**, for the same reason: there is no author source
+    to rewrite, because the shape was never reachable from an authoring surface.
+    The channel for code consumers is `api-surface.json` (which lost all three
+    `HttpServerConfig*` entries) feeding the release-time `spec-changes.json`
+    diff, plus this changeset.
+  - Baselines updated deliberately: `json-schema.manifest.json` (−1, the #2978
+    ratchet fired first and demanded it), `authorable-surface.json` (−9, allowed
+    by the #4650 gate's path 3 "def no longer emitted by this build"),
+    `api-surface.json` (−3). Reference docs and the strictness-ledger counts
+    regenerated.
+  - **The container, not the file.** `RouteHandlerMetadata` (consumed by
+    `packages/rest`) and `MiddlewareType` / `MiddlewareConfig` (consumed by
+    `packages/runtime`) stay, as do `CorsConfigSchema`, `RateLimitConfigSchema`
+    and `StaticMountSchema` in `shared/http.zod.ts` — each has live consumers
+    outside the retired shape, so none of them was orphaned by it.
+
+  No runtime behaviour changes — that impossibility is the reason for the removal.
+
+- 72c3c86: refactor(spec)!: retire `indexes[].type` and `indexes[].partial` — two authorable index keys no driver ever read (#5248, #4943)
+
+  `IndexSchema` declared five keys; only three of them ever reached a `CREATE
+INDEX`. `SqlDriver.syncDeclaredIndexes` builds every declared index through
+  knex's `table.index(fields, name)` / `table.unique(fields, { indexName })`, and
+  the drift differ's `DeclaredIndexInput` carries `name` / `fields` / `unique` /
+  `nullSafeColumns`. So:
+
+  - **`partial`** — documented as _"Partial index condition (SQL WHERE clause)"_ —
+    produced a **full** index with the predicate silently discarded. This was the
+    damaging half, because it reads as a correctness control: the platform's own
+    `sys_metadata` declared `partial: "state = 'active'"` for overlay uniqueness,
+    and what the declaration alone materialized was an _unrestricted_ unique index.
+  - **`type`** additionally carried `.default('btree')`, so it appeared in **every**
+    parse output of **every** index — an access-method knob that had never
+    influenced a single statement, rendered as live configuration. (It was pinned
+    as such in a `sys_presence` test, on an object that never declared it.)
+
+  Both are the ADR-0078 no-silently-inert / ADR-0049 enforce-or-remove shape.
+  Remove was chosen over enforce: enforcing needs per-dialect algorithm mapping
+  (`gin`/`gist` Postgres-only, `fulltext` MySQL-family), raw-SQL `CREATE INDEX …
+WHERE` on the dialects that have partial indexes at all (MySQL does not), and a
+  redesign of how `isSyncReproducibleIndex` excludes partial indexes from
+  incremental sync — design cost for a capability with no demand. If a real need
+  appears it returns enforce-first.
+
+  ## Migration
+
+  | FROM                                                      | TO                                                                                              |
+  | :-------------------------------------------------------- | :---------------------------------------------------------------------------------------------- |
+  | `indexes: [{ fields: […], type: 'gin' }]`                 | `indexes: [{ fields: […] }]` — create the specialised index from a database-layer migration     |
+  | `indexes: [{ fields: […], partial: "state = 'active'" }]` | `indexes: [{ fields: […] }]` — issue `CREATE [UNIQUE] INDEX … WHERE …` from a runtime migration |
+
+  **One-line fix: delete the key.** Neither removal changes any DDL, because no
+  DDL ever depended on them — verified byte-for-byte against the `CREATE INDEX`
+  statements SQLite actually stores
+  (`packages/drivers/driver-sql/src/declared-index-retired-keys.test.ts`).
+
+  Both capabilities remain available where they are implementable. The index
+  method is the driver/dialect's choice. A partial index is issued as raw SQL from
+  a runtime migration — exactly what `metadata-protocol`'s `ensureOverlayIndex`
+  already does for `sys_metadata`, and what actually delivers that table's
+  active-row-scoped uniqueness today.
+
+  ⚠️ **Not affected:** driver-sql's own `partial` flag (`parseIndexDdl` /
+  `introspectIndexes` / `isSyncReproducibleIndex`). That is a boolean parsed back
+  out of the _database's own_ DDL for drift detection — the opposite direction —
+  so migration-created partial indexes stay recognized and exempt from incremental
+  sync, unchanged.
+
+  ## The retirement kit
+
+  - `retiredKey()` tombstones at `IndexSchema` (the shape is deliberately
+    `.strip()`, so a plain delete would swap one silent no-op for another): writing
+    either key is now a `tsc` error and a parse error carrying the prescription.
+    They sit at the bottom of the shape per the #5606 renderer note.
+  - **ADR-0087 D2 conversion + D3 chain step** (`object-index-type-partial-removed`,
+    `toMajor: 17`, wired into the existing step-17 chain): strips both keys from
+    `objects[]` and `objectExtensions[]`; `os migrate meta --from 16` rewrites sources
+    mechanically. A pure lossless delete — there was no effect to lose.
+  - **Producers flipped:** `sys_metadata` (`idx_sys_metadata_overlay_active`, the
+    case #4943 named) and `sys_view_definition` (`idx_sys_view_def_active`), both
+    with their comments corrected to say what is actually materialized.
+  - Published skill (`objectstack-data`), `content/docs/data-modeling/objects.mdx`,
+    liveness ledger note and generated baselines updated.
+
+- 26e1029: 退役 `NotificationActionSchema` / `EmbedConfigSchema`——两个从来没有授权门的 `./ui` 词汇表形状（ADR-0049 enforce-or-remove，#5015）
+
+  ## FROM → TO
+
+  | 移除                                                                        | 改为                                                                                                                                                          |
+  | --------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+  | `NotificationActionSchema` / `NotificationAction`（`@objectstack/spec/ui`） | **无替代形状**。删掉 import 和值。通知的呈现词汇仍在：`NotificationTypeSchema` / `NotificationSeveritySchema` / `NotificationPositionSchema` 三个枚举原样保留 |
+  | `EmbedConfigSchema` / `EmbedConfig`（`@objectstack/spec/ui`）               | **无替代形状**。删掉 import 和值。表单的公开访问由**活门** `FormView.sharing`（`SharingConfigSchema`）授予，该门未受本次变更影响                              |
+
+  一行修复:删除 import 与值本身 —— 没有任何一份元数据源码需要改写,因为这两个形状**从来就没有键可以写进去**。升级后再 import 是 TS2305。
+
+  ## 为什么是移除而不是收紧
+
+  这一档比「声明了但没人读」还要低一级:**连键都没有**。#4001 批 14 在 2026-08-03 对这两个形状做了三条独立测量,本次退役在 `origin/main` 上把三条全部重跑,每条都带同一次运行内通过的阳性对照:
+
+  1. **承载键** —— `packages/spec/src` 里没有任何 schema 声明这两个类型的键。`ui/notification.zod` 的非测试 importer 只有 barrel;`ui/sharing.zod` 的是 barrel 加 `ui/view.zod.ts`,而后者点名的是它的**兄弟** `SharingConfigSchema`。匹配按 specifier **解析**而非子串比对 —— 仓里有两个 `sharing.zod`,子串法会把 `stack.zod.ts` 误记为 UI 那个的 importer。
+  2. **图可达性** —— 从 24 个 metadata-type root 加 `defineStack` 的 `ObjectStackSchema` 做 BFS（`build-schemas.ts` 自己的走法,含 derived-clone 桥接）两个都走不到,而 `Page` / `Action` / `DashboardWidget` / `Webhook` 以及 `SharingConfig` 本身在同一次运行里全部 `root-graph`;注入一个合成承载键后两个都翻成 `root-graph`。
+  3. **调用点** —— objectstack / cloud / objectui 三个仓里,除各自单测外零 `.parse()`。
+
+  所以没人写得进去,也从来没有东西校验过它们:这正是 #3950 记录的形状 —— 一个没有消费者的导出 schema 会被当成能力来读,而 ADR-0033 的 AI 作者会把 `EmbedConfigSchema` 出现在发布包里当作「平台支持 iframe 嵌入」的证据。
+
+  批 14 **故意没有**用 `.strict()` 收紧它们:strict 是一次 **parse** 的属性,对没人 parse 的形状收紧什么也不强制,只会留下*「一个被精确校验的死槽位 —— 更有说服力的谎言」*（#4583）。批 14 把判定挂成 #5015,本次是该判定的执行,裁决 REMOVE（2026-08-04）。
+
+  两个形状各自都是**上一层退役留下的孤儿**,这也是它们成为孤儿的原因:
+
+  - `NotificationAction` 在 #4610 失去了两个 wrapper（`NotificationSchema` / `NotificationConfigSchema`,因零消费者被删）;
+  - `EmbedConfig` 在 17.0.0 失去了它的键 —— 2026-06 liveness audit 退役了 `App.embed`（从来没有 iframe 路由读过它),该键至今作为 `retiredKey()` 墓碑立在 `app.zod.ts`。也就是说**写了那个键的作者早就会撞到处方**,本次删掉的是比键活得更久的值形状。
+
+  ## ⚠️ 范围:按 SCHEMA 退役,不是按文件
+
+  两个模块都**存活**,并且都保留活导出:
+
+  - `ui/sharing.zod` 保留 `SharingConfigSchema` —— 这是一个**活门**:`FormViewSchema.sharing` 承载它,`rest-server.ts` 真的读 `sharing.allowAnonymous` / `sharing.publicLink` 来挂匿名表单路由,两个示例应用都在写。**公开表单分享不受影响**;
+  - `ui/notification.zod` 保留三个呈现枚举。
+
+  `packages/spec/src/ui/notification-embed-retirement.test.ts` 把两侧都钉住:缺席按 resolved symbol identity across 每个 public entry 断言,**存活侧同样是承重的** —— 一次连文件一起删掉的「退役」能满足全部缺席断言,却会摧毁正在工作的面。
+
+  ## 运行时行为
+
+  字节级不变:从来没有一个 notification action 被从元数据里解析出来,也从来没有 iframe 路由读过 embed config。
+
+  ## 生成物基线的删除是有意的
+
+  `json-schema.manifest.json` 少 2 个 key,`authorable-surface.json` 少 10 行,`api-surface.json` 少 4 个导出。这是**整 def 删除**路线的预期读数（而非枚举值收窄那种四张 ratchet 全无变化的形态):`#2978` manifest ratchet 先开火要求有意删除 manifest key,删完重跑后 per-key ratchet 自行判定为 #4650 路径 3（`def no longer emitted by this build`）。
+
+  ## objectui 侧
+
+  objectui 的 `animation-notification-spec-parity.test.tsx` 把 `NotificationActionSchema.shape.variant` 当**词汇表**读（不是 parse),用来双向 pin 它自己手写的 `NotificationActionButton` 接口。这恰好说明「有消费者」不等于「有授权门」。该 pin 会在 objectui 刷新本依赖时失去 spec 侧锚点,适配在 objectui 侧单独跟进 —— 本次变更不碰 objectui。
+
+- 108ba8d: **Object inner blocks now reject unknown keys instead of dropping them (#4001 批 20).**
+
+  Thirteen object shapes nested inside `data/object.zod.ts` were still zod's default
+  `.strip`: a key the schema did not declare was discarded and the parse still
+  succeeded. The object's TOP level has rejected unknown keys since #1535/#4519/#4522,
+  and that asymmetry is what made this the batch worth doing — an author who has _seen_
+  the root reject a typo has every reason to read a clean parse of
+  `lifecycle: { maxAge: '30d' }` as acceptance. `object` carries the highest author
+  volume in the repo.
+
+  Closed, each reached through its real carrier key and probed there (strictness does
+  not recurse, so a closed parent proves nothing about a nested block):
+
+  - `access` — the ADR-0066 D2 exposure posture.
+  - `lifecycle` **and all four sub-blocks** — `retention`, `ttl`, `storage`, `archive`.
+  - `fieldGroups[]` — the ADR-0085 group entry.
+  - `external` — the ADR-0015 federated binding.
+  - `userActions`, `systemFields`, `activityMilestones[]`, `publicSharing`.
+  - `objectExtensions[]` — the extension entry (`defineObjectExtension`).
+
+  **Migration.** Any key now rejected was previously stripped and had no runtime
+  effect — the error carries the fix. The dominant real-world mistake on this file is
+  **flattening**, so `lifecycle` points DOWN into the sub-block that owns each key:
+  `maxAge` → `retention`, `expireAfter`/`field` → `ttl`, `strategy`/`shards`/`unit` →
+  `storage`, `after`/`to`/`keep` → `archive`. That one matters beyond tidiness: a
+  flattened `maxAge` leaves `retention` absent, so ADR-0057 §3.5 then rejected the
+  object as _unbounded_ — an error naming the wrong key entirely.
+
+  Other wrong-layer pointers, each anchored to a named sibling contract:
+  `userActions.sort`/`search`/`filter`/`editInline` point at `ui/view.zod.ts`'s
+  identically-named block, whose vocabulary is completely disjoint from the object's;
+  `userActions.clone` points at `enable` (ObjectCapabilities); `systemFields.owner`
+  points at `ownership` — a key the block's own field doc names but the shape never
+  declared; `external.allowWrites` names the ADR-0015 double opt-in and mirrors
+  `datasource.zod.ts`'s own `writable → allowWrites` alias in the opposite direction;
+  `access.sharingModel` and `publicSharing.sharingModel` point up at the top level and
+  distinguish link sharing from principal sharing; `fieldGroups[].fields` states the
+  direction of the membership edge (declared on the FIELD, as `group:`);
+  `objectExtensions[].actions`/`hooks`/`listViews` say plainly that the merge has no
+  slot for them and name the route that does. Aliases cover the near-misses distance
+  cannot reach (`export` → `exportCsv`, `audiences` → `allowedAudiences`, `table` →
+  `remoteName`, `object` → `extend`, …). `fieldGroups[]`'s three DEPRECATED collapse
+  aliases stay **accepted** — closing a shape must not turn a documented deprecation
+  into a rejection.
+
+  **`IndexSchema` is deliberately NOT closed, and that hold is the batch's finding.**
+  The console ships its own hand-copied JSON-Schema for this shape (objectui
+  `metadata-admin/EmbeddedItemEditor.tsx`), because `index` is an embedded-only
+  sub-type the framework publishes no schema for — and that copy has drifted: it
+  offers **`where`** for the partial-index predicate where the spec declares
+  **`partial`**. The editor splices its output into `object.indexes[]` and PUTs the
+  whole object, and `saveMetaItem` keeps the body verbatim while validating it, so
+  closing this one shape would 422 a control the console itself renders (the #5114
+  class, caught this time _before_ shipping rather than after). The capability is
+  already dead in both directions — `driver-sql`'s `syncDeclaredIndexes` reads
+  `name`/`fields`/`unique` only, so neither spelling reaches any DDL — which is
+  exactly why the close is gated on both the producer rename and an ADR-0049 answer
+  for `type`/`partial`: pointing an author at `partial` today would be a guidance
+  entry claiming more than the platform delivers.
+
+  One caveat shipped knowingly: `systemFields` is a `false | {…}` union, so its
+  rejection is an `invalid_union` whose own message is the bare _"Invalid input"_ —
+  the #5014 flattening. 批 18's `discriminatedUnion` fix is unavailable here (one arm
+  is a literal, so there is no discriminant to key on), so the behaviour is pinned
+  honestly rather than papered over. Every other site in the file is a plain object
+  and surfaces its prescription directly.
+
+- 7d27da0: **`@objectstack/spec/openapi.json` 不再描述任何路由 —— 静态产物收缩为它真正拥有的契约半边(#5744,#5588 裁定 C 第二棒)**
+
+  `packages/spec/scripts/build-openapi.ts` 里手写的 built-in 路由段(`generateCrudPaths` / `generateMetadataPaths` / `generateDiscoveryPaths`,7 条 path、10 个 operation)整体摘除。这一段在真实 boot 上逐条探测 **0/10 命中**:路径按字面量 `basePath = '/api'` 拼接,于是全部缺 `/v1`(CRUD 还缺 `/data`);`PUT {object}/{id}` 的动词服务器明确回 405;`/api/meta/types` 全仓无此路由;`/api/.well-known/objectstack` 是 runtime dispatcher 的路由、挂在**根路径**上。而且它在这个座位上原理上就写不对 —— `apiPath` 是部署级配置(`api.apiPath ?? api.basePath + '/' + version`),随包发布的静态 JSON 无法为所有部署拼对前缀。
+
+  段落的唯一属主是**挂载这些路由的包**(ADR-0076 一路由一属主;本文档的属主由 #5078 的真实 boot 坐实为 `@objectstack/rest`)。第一棒 #5821 已让 REST 服务在 serve 期从 `routeManager.getAll()` 产出该段、并**整体丢弃**静态产物带来的 `paths`,所以本次摘除对服务出的 `GET {apiPath}/openapi.json` 是**零行为变化**:那份文档的路由段早已逐字节来自 rest。
+
+  发布出去的静态产物现在只剩 `openapi` / `info` / `servers` / `components`(`schemas` + `securitySchemes`)/ `security` 五个顶层键 —— 正是 rest serve 期会从产物里读走的那几项。
+
+  **破坏性**:直接 `import '@objectstack/spec/openapi.json'` 的消费者会看到
+
+  - **`paths` 键消失**(不是变成 `{}`)。OpenAPI 3.1 里 `paths` 可省(`paths` / `components` / `webhooks` 三者有其一即为合法文档),而两种写法说的不是一件事:`paths: {}` 断言「这个 API 什么都不服务」——假的;键不存在则对路由不作任何断言 —— 这才是这份产物有资格作出的声明。`doc.paths` 上直接取值的代码需要改成防御式读取,或者改去读服务出的 `GET {apiPath}/openapi.json`(那份是完整文档)。
+  - **`tags` 键消失**。`CRUD` / `Metadata` / `Discovery` 三个 tag 只为命名被摘掉的三段而存在,任何文档里都没有 operation 携带它们;服务出的文档的 tag 列表由 rest 与路由段一起产出。
+
+  要一份**带路由**的文档,唯一正确的来源是运行中的服务:`GET {apiPath}/openapi.json`。
+
+  **门禁随形状调整,不靠留活口维持覆盖**:#5168 的产物自恰门保留,但如实标注 —— 9 个 `$ref` 全部住在被摘掉的 operation 请求/响应体里,所以 `assertRefsResolve` 在**今天**的产物上是空断言。留着它是因为幸存的那半边仍然能走到它防的形状:`z.toJSONSchema` 会把复用/递归子 schema 放进它**返回值**根部的 `$defs`,并用根相对的 `#/$defs/…` 指过去;这些 schema 各自独立转换后被停在 `components.schemas[Name]` 下,于是该指针指的是整份 OpenAPI 文档的根 —— 那里没有 `$defs`。九个契约 schema 今天都不是递归形状,反向验证用变异复现了这一天(注入 `#/$defs/Recursive` → 生成器非零退出)。另新增两条钉子:产物**不含**路由段(七条幽灵路径与三个 tag 逐条断言不存在),以及产物**仍完整保留** spec 拥有的五个顶层键 —— 后者防的是把这次收缩做过头、连 rest 要读的东西一起删掉。
+
+  `check:generated` 台账里 `gen:openapi` 那条 `why` 同步改写:原文「no check gate compares it to the routes」在裁定 C 之下已无第二方可对账,现在如实记录真正剩下的缺口 —— 没有任何东西把产物的 `components.schemas` 与 `src/api` 对账,产物过期不会让任何东西变红(自恰性由 #5168 在写盘前自检覆盖,**时效性**没有)。
+
+- 1c3da1f: **BREAKING (authoring gate tightens): `ViewItemSchema` is split into an authoring schema and a wire variant.**
+
+  `ViewItemSchema` used to carry two contracts at once — the authoring surface
+  `defineViewItem()` and Studio's view-create form parse, AND member 1 of the
+  `ViewMetadataSchema` union that `saveMetaItem` validates every persisted `view`
+  body against. Because the second role needs Studio's round-trip keys through,
+  the shape stayed open, and an authoring typo was silently dropped:
+
+  ```ts
+  defineViewItem({ name: 'crm_lead.pipeline', object: 'crm_lead', viewKind: 'list', confg: { … } })
+  // before: parsed clean → a ViewItem with NO view configuration at all
+  // after:  Unrecognized key(s) on this view item: `confg`. Did you mean `config`?
+  ```
+
+  **What changed**
+
+  - `ViewItemSchema` is now strict on both arms. It is the authoring gate.
+  - `ViewItemWireSchema` (new export) is the `.strip()` wire variant and is
+    member 1 of `ViewMetadataSchema`. It **declares** `isPinned` and `sortOrder`,
+    the Studio switcher keys the console round-trips.
+  - `ViewFilterRuleSchema` and the `ListView.sort[]` entry are now strict too,
+    and `ListView.sort[]` rejects `direction` with a pointer to `order` (the two
+    spell the same tuple, and the wrong one reversed the sort silently).
+  - New exports: `ViewItemWireSchema`, `ViewItemWire`, `stripViewConsoleDecorations`,
+    `VIEW_CONSOLE_ROW_DECORATIONS`.
+
+  **Migration — authored metadata (`*.view.ts`, `defineViewItem`, published packages)**
+
+  | you wrote                     | on a …                   | now                                                       |
+  | :---------------------------- | :----------------------- | :-------------------------------------------------------- |
+  | `confg:` / any undeclared key | view item                | rejected, with the closest declared key suggested         |
+  | `isPinned:`                   | view item                | remove it — per-user Studio state, written by the console |
+  | `sortOrder:`                  | view item                | use `order` for the authored default position             |
+  | `id:`                         | filter rule / sort entry | remove it — a console row key, never authored             |
+  | `direction: 'desc'`           | sort entry               | `order: 'desc'`                                           |
+
+  **Nothing changes for the console/write path.** The `view` metadata write door
+  still accepts every body the platform itself writes: pinning a saved view, the
+  column-sort PUT and the filter-save PUT all parse exactly as before. The
+  console's row `id`s are removed by `stripViewConsoleDecorations` before
+  validation — the write-path mirror of `stripReadDecorations` — and
+  `saveMetaItem` still persists the original body verbatim, so those ids
+  round-trip to the renderer untouched. `id` was deliberately **not** declared:
+  it is a React list key, and declaring it would put a UI artifact on the
+  authorable surface.
+
+- 4845f85: **The retry policy's last two dialects converge** (#4964 `flow.errorHandling`, #4962
+  `ETLPipeline.retry`).
+
+  #4661 converged the retry policy onto one declaration. It converged the two shapes that
+  published the **same exported name** (`RetryPolicy` from `./automation` and `./system` —
+  the #4411 trap), because that is the question the dual-source instrument asks. Two more
+  encodings of the identical concept were outside its vision _by construction_: both are
+  anonymous inline `z.object`s nested in a bigger schema, with no exported name to collide.
+
+  The cost of the gap fell on the author who did the right thing. `shared/retry-policy.zod.ts`
+  tombstoned `retryDelayMs` and told them to write `backoffMs` — and `flow.errorHandling`
+  then **rejected** `backoffMs` and demanded `retryDelayMs`. Reading the newer file was
+  punished, and which file an AI author reads first is arbitrary.
+
+  All four surfaces — `job.retryPolicy`, a `try_catch` node's `retry`, `flow.errorHandling`
+  and an ETL pipeline's `retry` — now build from one shared shape.
+
+  ## FROM → TO
+
+  ### `flow.errorHandling` (#4964)
+
+  |                                                                   | FROM                                | TO                                                                       |
+  | ----------------------------------------------------------------- | ----------------------------------- | ------------------------------------------------------------------------ |
+  | base delay                                                        | `retryDelayMs`, min 0, default 1000 | **`backoffMs`**, min 0, default 1000                                     |
+  | `maxRetries` / `backoffMultiplier` / `maxRetryDelayMs` / `jitter` | _(already identical)_               | unchanged                                                                |
+  | `strategy`                                                        | `'fail' \| 'retry' \| 'continue'`   | unchanged — it selects _whether_ the policy runs, so it stays outside it |
+
+  One key, one word, no default changes. Every other key, bound and default already
+  matched the converged policy, which is exactly why the divergence survived a release:
+  it looked reviewed.
+
+  ### `ETLPipeline.retry` (#4962)
+
+  |                     | FROM                                           | TO                                        |
+  | ------------------- | ---------------------------------------------- | ----------------------------------------- |
+  | count               | `maxAttempts`, min 0, **default 3**, unbounded | **`maxRetries`**, 0–**10**, **default 0** |
+  | base delay          | `backoffMs`, default **60000**                 | `backoffMs`, default **1000**             |
+  | `backoffMultiplier` | _(absent)_                                     | ≥1, default 1                             |
+  | `maxRetryDelayMs`   | _(absent)_                                     | default 30000                             |
+  | `jitter`            | _(absent)_                                     | default false                             |
+
+  ## What you must change
+
+  **1. Rename `retryDelayMs` → `backoffMs`** in any `flow.errorHandling` block. The value
+  (milliseconds before the first retry) is unchanged. The old spelling is **tombstoned**,
+  not deleted, so it rejects with the rename rather than being silently stripped, and
+  `os migrate meta --from 16` (the `retry-policy-converged` conversion, now with a
+  flow-level branch) rewrites it for you.
+
+  **2. Rename `maxAttempts` → `maxRetries`** in any `ETLPipeline.retry` block. **The number
+  does not change** — both counted the retries _after_ the initial attempt. Do **not**
+  subtract one: that adjustment belongs to `integration/connector.zod.ts`'s
+  identically-spelled `RetryConfig.maxAttempts`, which _includes_ the first attempt and is
+  deliberately **not** part of this convergence.
+
+  **3. If an ETL pipeline relied on the implicit retry count, write it out.** `retry: {}`
+  used to mean three re-runs 60s apart; it now means **none**. State `maxRetries: 3` (and
+  `backoffMs: 60000` for the old delay) to keep the old behaviour.
+
+  ## Why the ETL default flips to 0
+
+  Not merely to follow #4661. An ETL destination is a foreign system _by definition_ — a
+  warehouse, an API, someone else's database. A silent retry against a non-idempotent
+  destination is a **duplicate write**: a second invoice, a second export, a second
+  webhook. Default 0 makes retrying something an author states, and thereby claims
+  idempotency for. An unstated key is precisely where LLM-authored metadata hides this.
+
+  ## Migration surface
+
+  **`flow.errorHandling`** is live: `service-automation`'s `retryExecution` reads the key
+  (it now destructures `backoffMs`), and the D2 conversion covers stored and authored
+  flows, so no deployed stack changes behaviour.
+
+  **`ETLPipeline.retry` has an empty migration surface today, and that is why now was the
+  moment.** `etl.zod.ts` has no parse site in objectstack / objectui / cloud (批 12's
+  measurement) and an ETL pipeline is not a `defineStack` collection, so there is no stored
+  document a conversion could walk — it deliberately gets a tombstone and **no** D2 step,
+  rather than a walker advertising coverage that does not exist. Once an ETL engine lands,
+  flipping this default stops being a schema edit and becomes a behaviour change to every
+  deployed pipeline.
+
+  ## Also
+
+  The two automation retry surfaces now carry the **same** curated unknown-key table, so an
+  author learns one lesson instead of two, and `retry-policy.test.ts` gains a
+  concept-level guard: all four surfaces are asserted to expose the same key set and the
+  same defaults, by parse rather than by inspecting how each obtains them. Adding a fifth
+  retry surface without wiring it to the shared shape now fails a test — which is the check
+  that would have caught both of these issues, and the one the name-based scan could never be.
+
+- f61c8cf: feat(spec,metadata-protocol)!: a sort node spelling its direction `direction` is a 400, not a silently reversed page (#4721)
+
+  **FROM → TO:** `orderBy: [{ field: 'updated_at', direction: 'desc' }]` →
+  `orderBy: [{ field: 'updated_at', order: 'desc' }]`. One word. If you are on the
+  `{field, direction}` shape because you moved code over from
+  `IReportService.orderBy`, that contract is unchanged — it is `orderBy` on the
+  QueryAST / `EngineQueryOptions` axis that has always been `{field, order}`.
+
+  ## What was wrong
+
+  `SortNodeSchema` was a plain `z.object`, so zod's default `.strip` applied.
+  Measured on `main` before this change:
+
+  ```
+  SortNodeSchema.parse({ field: 'updated_at', direction: 'desc' })
+    →  { field: 'updated_at', order: 'asc' }
+  ```
+
+  `direction` was discarded and `order` fell back to its `asc` default. The sort
+  therefore ran in the **opposite** direction and the request succeeded. Paired
+  with `limit` — which is how a caller asks for "the latest N" — that is not a
+  reordered page but a **different set of rows**, returned under an ordinary 200
+  with nothing in the response to distinguish it from the answer that was asked
+  for.
+
+  `direction` is not a typo. It is the live vocabulary of a neighbouring contract,
+  `IReportService.orderBy` (`@objectstack/spec/contracts`), and
+  `plugin-auth/objectql-adapter.ts` already translates between the two by hand — a
+  translation known to be necessary and enforced nowhere, which is the ADR-0049
+  shape.
+
+  ## What changed
+
+  Both doors onto that shape, in one change:
+
+  1. **`SortNodeSchema`** (`spec/src/data/query.zod.ts`) is now `strictObject`
+     with `aliases: { direction: 'order' }`. An unknown key is rejected, and
+     `direction` specifically gets the translation in the error message — edit
+     distance can never bridge `direction` → `order`, so a bare "unrecognized key"
+     would leave the caller exactly where the silent strip did.
+  2. **`normalizeSortNodes`** (`metadata-protocol/src/protocol.ts`), the ingress
+     every REST/RPC `orderBy` funnels through, refuses `{ field, direction }` with
+     `400 INVALID_SORT` naming `order` and quoting the corrected node. Closing only
+     the schema would repeat the door asymmetry of #1535/#4522: `SortNodeSchema` is
+     reachable by three paths the REST normalizer never sees.
+
+  | `orderBy` you send                                     | Before                      | After                                                       |
+  | :----------------------------------------------------- | :-------------------------- | :---------------------------------------------------------- |
+  | `[{ field: 'x', order: 'desc' }]`                      | descending                  | unchanged — descending                                      |
+  | `[{ field: 'x', direction: 'desc' }]`                  | **200, ascending**          | `400 INVALID_SORT`, message names `order`                   |
+  | `[{ field: 'x', order: 'desc', direction: 'asc' }]`    | 200, descending             | `400 INVALID_SORT`                                          |
+  | `'-x'` / `['-x']` / `{ x: 'desc' }`                    | descending                  | unchanged                                                   |
+  | `{ direction: 'desc' }` (the `{field: direction}` map) | sorts by column `direction` | unchanged — a column may legitimately be called `direction` |
+
+  Scope is deliberately narrow: **`QuerySchema`'s top level is untouched** and
+  still accepts undeclared keys (`QuerySchema.safeParse({ object: 'sales',
+nonsenseKey: 1 }).success === true`). That is tracked in the #4001 campaign map
+  for its own batch, not smuggled in here.
+
+  Related: #4674, #4720, #4363, #4371, #4001, ADR-0049.
+
+- efedd28: refactor(spec)!: retire `IStorageService.list(prefix)` — one contract method, two adapter dialects, both silently incomplete, and no caller (#5540, ADR-0049 enforce-or-remove)
+
+  `list?(prefix)` was an optional method on the storage contract, documented as
+
+  > List files in a directory/prefix
+
+  and the two shipped adapters answered the same call with two different meanings.
+  Neither told you.
+
+  **The local adapter listed one level and counted directories as files.**
+  `LocalStorageAdapter.list` was a plain `readdir` over the prefix directory, so a
+  nested key `a/b/c` was invisible under `list('a')` — you got `a/b` — and every
+  subdirectory that `stat` succeeded on was pushed into the result as if it were a
+  file, producing a `StorageFileInfo` whose `size` is a directory inode and which
+  `download()` cannot fetch.
+
+  **The S3 adapter recursed and stopped at 1000.** `S3StorageAdapter.list` issued
+  one `ListObjectsV2` with the prefix — which matches the whole key, so it is
+  recursive, not one level — and read neither `IsTruncated` nor
+  `ContinuationToken`. Past 1000 objects, the "all files under this prefix" a
+  caller received was the first page, with nothing to distinguish it from a
+  complete answer.
+
+  So the same call was one-level-plus-junk on one deployment and
+  recursive-but-truncated on the other, and the first feature that genuinely
+  needed to enumerate a prefix — backup, orphan sweep, migration audit — would
+  have got two different wrong answers and no error on either.
+
+  **Nothing called it.** The only call site in the repository was the
+  `SwappableStorageService` pass-through, which rejects anyway when the active
+  adapter has no `list`. REST, the CLI and the storage routes never called it.
+  #5172 came closest: it planned to reclaim email-attachment content by listing
+  `EMAIL_ATTACHMENT_KEY_PREFIX`, discovered the local adapter could not see one
+  level down, and switched to queue-driven deferred work — the divergence cost a
+  design, and the method still had no consumer afterwards.
+
+  **Migration.**
+
+  | Wrote                                                      | Write instead                                                                                                                    |
+  | ---------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
+  | `await storage.list('attachments/task/')`                  | query the records you wrote — `sys_file` / file-reference rows carry the storage key and page deterministically through ObjectQL |
+  | `list?(prefix) { … }` on your own adapter                  | delete the method (see below)                                                                                                    |
+  | `if (typeof storage.list === 'function')` capability probe | delete the branch; the contract has no `list` to probe for                                                                       |
+
+  Querying your own records is not a workaround for the missing method — it is the
+  only form that was ever correct across both backends and past 1000 objects. The
+  bucket was never the system of record for "which files exist"; the rows are.
+
+  **Adapter authors: nothing breaks on you.** An implementation left in place still
+  compiles — an extra method is not an error on a class — it is simply unreachable
+  through the contract, so deleting it is cleanup you can do whenever. The break is
+  on the **caller** side: `storage.list(...)` no longer type-checks. That includes a
+  _proxy_ typed against `IStorageService` that forwards to `inner.list`; the one in
+  `@objectstack/service-storage` is removed with the adapters in #5541.
+
+  **No tombstone, deliberately.** `IStorageService` is a contract that code
+  _implements_; nothing anywhere runs a storage adapter through a `.parse()`, so a
+  `retiredKey()` prescription would have no one to reach. The channel that can
+  carry it is `tsc`, and `tsc` reports it where it is actionable — at the call
+  site. This is the same disposition, for the same reason, as
+  `IDataDriver.findStream` (#4484). The retirement is registered as the
+  `storage-service-list-retired` semantic entry in the protocol-17 chain step
+  (ADR-0087 D3), so `spec-changes.json`, the generated upgrade guide and the
+  `spec_changes` MCP tool all carry it. There is no `os migrate meta` step: an
+  adapter is code, never stack metadata, so the chain has no source to rewrite.
+
+  **No replacement, on purpose.** A prefix listing that cannot paginate is the
+  wrong signature to inherit. If a first-party caller ever needs real bucket
+  enumeration it comes back cursor-shaped — `list(prefix, { cursor, limit })`
+  returning a page plus a continuation token — with adapter-conformance cases
+  (nested keys, directory entries, more than 1000 objects) proving both backends
+  agree before either ships. Maintainer ruling 2026-08-05 on #5266 chose this over
+  aligning the two adapters, which would have grown a conformance surface nobody
+  walks.
+
+- 5278e11: **BREAKING** — `automation/control-flow` and `automation/state-machine` reject unknown keys (#4001 批 10, ADR-0078)
+
+  Eleven authoring shapes that silently discarded undeclared keys now refuse them with a
+  named surface, the offending key echoed back, and a rename or prescription. Metadata that
+  used to parse "successfully" while losing the key you wrote now returns 422.
+
+  **`automation/control-flow.zod.ts`** — `FlowRegionSchema`, `LoopConfigSchema`,
+  `ParallelBranchSchema`, `ParallelConfigSchema`, `TryCatchConfigSchema`.
+
+  **`automation/state-machine.zod.ts`** — `ActionRefSchema` (object branch),
+  `GuardRefSchema` (object branch), `TransitionSchema`, `StateNodeSchema`, its `meta` block,
+  and `StateMachineSchema`.
+
+  ## What was actually being lost
+
+  A `state_machine` on an agent's `lifecycle` with `onn` where `on` was meant parsed clean
+  and came back with **no transitions at all** — the declaration whose entire purpose is to
+  deny undeclared transitions, silently emptied and reported valid. A `loop` config with
+  `maxIteration` (singular) came back uncapped. A `parallel` branch with `label` instead of
+  `name` came back unnamed.
+
+  ## Migration — FROM → TO
+
+  Renames the rejection now suggests for you:
+
+  | you wrote                | write instead      | on                                                                                 |
+  | ------------------------ | ------------------ | ---------------------------------------------------------------------------------- |
+  | `guard`                  | `cond`             | a state transition (XState v5 renamed it the other way; this protocol kept `cond`) |
+  | `action`                 | `actions`          | a state transition                                                                 |
+  | `itemVariable`           | `iteratorVariable` | a `loop` config                                                                    |
+  | `maxIteration`           | `maxIterations`    | a `loop` config                                                                    |
+  | `label`                  | `name`             | a `parallel` branch                                                                |
+  | `onn` / `entery` / typos | `on` / `entry`     | a state node                                                                       |
+
+  Keys with no replacement, and what to do instead:
+
+  - **`finally` on `try_catch`** — there is no `finally` region. The node's ordinary
+    out-edges run whichever way the protected region went; put the always-run steps in the
+    nodes **after** the container.
+  - **`join` / `joinGateway` on `parallel`** — the join is implicit; the block continues once
+    when every branch completes. `join_gateway` is a BPMN interop node type, never a
+    `parallel` config key.
+  - **`flowName` on `loop`** — that key belongs to the `map` node, which runs a subflow per
+    item. A `loop` runs an inline region: move the steps into `config.body`, or change the
+    node `type` to `map`.
+  - **`name` / `label` on a region** — a `loop` body, a `try` region and a `catch` region are
+    not named; only a `parallel` branch carries a `name`.
+  - **`transitions` on a state node** — a state node declares transitions as `on`, keyed by
+    event type. `transitions` is the key on the object-level `state_machine` **validation
+    rule** (`validations[].transitions`), a different declaration.
+  - **`context` on a state machine** — this protocol declares only the context SHAPE, as
+    `contextSchema`. There is no key for seeding initial values, so the two are not a rename
+    of each other.
+
+  ## Two notes for upgraders
+
+  `ActionRef` / `GuardRef` are unions, so a rejected key on their object branch surfaces as
+  zod's `invalid_union` (`"Invalid input"`) with the real prescription nested one level down
+  in `issue.errors[]` rather than in the top-level message. The prescription is present in
+  `ZodError.message` and in REST error bodies; single-line formatters drop it.
+
+  `StateNodeSchema.meta` is **closed**, not a passthrough bag. XState treats `meta` as open,
+  but the hand-written `StateNodeConfig` type here declares exactly `label` / `description` /
+  `color` / `aiInstructions`, nothing in the platform reads any other key, and the previous
+  behaviour was not openness but strip — an authored `meta` arrived as `{}`.
+
+  All three example apps (`app-showcase`, `app-crm`, `app-todo`) validate unchanged, so no
+  ADR-0087 conversion accompanies this change.
+
+- f8cfbb4: **BREAKING (theme):** retire the nine theme token groups that were emitted and read by nobody (#5021, ADR-0049 enforce-or-remove).
+
+  `ThemeSchema` declared a full design-token vocabulary — a type scale, a weight
+  scale, line-height and letter-spacing scales, a motion scale and a z-index scale.
+  objectui's theme engine turned every one of them into CSS custom properties,
+  faithfully and for years. What never existed was a **reader**: measured against
+  objectui `main` on 2026-08-04, `--font-size-*`, `--font-weight-*`,
+  `--line-height-*`, `--letter-spacing-*`, `--duration-*`, `--timing-*`, `--z-*`,
+  `--font-heading` and `--font-mono` have **zero** consumers across objectui's
+  components and stylesheets, while `--font-sans`, `--radius*`, `--shadow*` and the
+  colour variables come back live in the same run. So a declared type scale was
+  real CSS that styled nothing, and an overlay you "lifted" with `zIndex` still
+  stacked by document order.
+
+  This is why the earlier theme sweep (#3494) left them standing: its criterion was
+  _"the engine never emits it"_, and these are emitted. ADR-0049's criterion —
+  emitted, but consumed by nobody — is what reaches them.
+
+  FROM → TO:
+
+  | Removed                               | Replace with                                                            |
+  | ------------------------------------- | ----------------------------------------------------------------------- |
+  | `theme.typography.fontSize`           | `theme.customVars: { "font-size-lg": "1.125rem" }`                      |
+  | `theme.typography.fontWeight`         | `theme.customVars: { "font-weight-semibold": "600" }`                   |
+  | `theme.typography.lineHeight`         | `theme.customVars: { "line-height-relaxed": "1.75" }`                   |
+  | `theme.typography.letterSpacing`      | `theme.customVars: { "letter-spacing-wide": "0.025em" }`                |
+  | `theme.typography.fontFamily.heading` | `theme.customVars: { "font-heading": "Georgia, serif" }`                |
+  | `theme.typography.fontFamily.mono`    | `theme.customVars: { "font-mono": "ui-monospace, monospace" }`          |
+  | `theme.animation`                     | `theme.customVars: { "duration-fast": "150ms", "timing-ease": "ease" }` |
+  | `theme.zIndex`                        | `theme.customVars: { "z-modal": "1050" }`                               |
+
+  The one-line fix: **delete the key; re-declare under `customVars` only the
+  variables your own stylesheets actually read.** `customVars` emits each entry
+  verbatim as `--<key>: <value>`, so every retired variable is reproducible byte
+  for byte — no capability is lost. Run `os migrate meta --from 16` to strip the
+  keys automatically; it emits one notice per key so you can see what you were
+  declaring before deciding what to keep.
+
+  `colors`, `borderRadius`, `shadows` and `typography.fontFamily.base` have live
+  consumers and are **unchanged**.
+
+  The retirement kit:
+
+  - **Schema** — each key is a `retiredKey()` tombstone, so authoring one is both
+    a `tsc` error (the input type is `never`) and a parse error carrying the
+    prescription above. `AnimationSchema` and `ZIndexSchema` were deleted outright
+    along with the `Animation` / `ZIndex` types: each had exactly one consumer —
+    the key now tombstoned — and an exported schema with no consumer reads as a
+    capability to whoever finds it (#3950).
+  - **Aliases** — the five that pointed at `animation`/`zIndex` and the seven that
+    pointed into the retired typography scales were deleted with their targets
+    rather than re-pointed. Keeping them would answer an author with _"did you mean
+    `zIndex`?"_ and then reject `zIndex` — a rename into a second rejection.
+  - **Migration** — `theme-inert-token-scales-removed` (ADR-0087 D2), wired into
+    the protocol-17 chain step and retired from the load path, so a live parse
+    rejects loudly and only `os migrate meta` rewrites sources. It **deletes** the
+    keys rather than auto-populating `customVars`: a rewrite would hand back two
+    dozen variables that still nothing reads, turning a dead semantic slot into a
+    dead literal one.
+  - **Baselines** — `authorable-surface.json` gains eight `[RETIRED]` markers and
+    loses the ten `ui/Animation:*` / `ui/ZIndex:*` lines under the #4650 deletion
+    check's whole-def proof; `json-schema.manifest.json` drops the two defs.
+
+- c89d18c: refactor(spec)!: retire the five `ui/` interaction config modules — a documented vocabulary with no carrier key anywhere (#4988)
+
+  `@objectstack/spec/ui` exported five interaction-configuration modules —
+  `touch.zod.ts`, `dnd.zod.ts`, `keyboard.zod.ts`, `animation.zod.ts` and
+  `offline.zod.ts` — carrying **22 `z.object` sites, 32 emitted defs and 64
+  exported names**. All five are removed, and their generated reference pages with
+  them.
+
+  Nothing in the protocol ever carried them. There was no `touch:` / `dnd:` /
+  `keyboard:` / `animation:` / `offline:` key on any schema, so no metadata
+  document could reach these shapes and nothing ever parsed one.
+
+  Three measurements, each re-run on `origin/main` immediately before the removal,
+  each with its controls passing in the same run:
+
+  1. **Static** — no module under `packages/spec/src` imported any of the five
+     except the `ui/index.ts` barrel, so no schema declared a carrier key.
+  2. **Graph** — a BFS over the in-memory Zod graph from all 24 metadata-type
+     roots plus `defineStack`'s `ObjectStackSchema` (25 roots, 4742 nodes) reached
+     **none** of the 21 named object shapes, while `PageSchema`, `WebhookSchema`
+     and `StateMachineSchema` all resolved `direct`, and injecting a synthetic
+     carrier flipped all 21 to `direct`. So "unreachable" was a fact about the
+     graph, not a broken walker.
+  3. **Call sites** — zero `.parse()` / `.safeParse()` in objectstack, objectui or
+     cloud outside these modules' own unit tests. objectui holds type re-exports
+     and parity ratchets, never validators, and says so (#2561).
+
+  **The defect was on the documentation side, and that is what made it urgent.**
+  `authorable-surface.json` listed **109 keys** under these defs and
+  `content/docs/references/ui/{touch,dnd,keyboard,animation,offline}.mdx` rendered
+  them as authoring tables. An AI author reading `dnd.mdx` and writing a `dnd:`
+  block onto a page component was rejected by `PageComponentSchema` for an
+  unrecognized key — the published docs and the schema disagreeing about what the
+  platform does (Prime Directive #10). This was never a strictness question:
+  `.strict()` is a property of a parse, and there was no parse.
+
+  Business ruling (2026-08-04): these five categories are **renderer built-in
+  behavior** — touch targets, drag-and-drop, focus and shortcuts, motion are
+  decided by the component library, not authored per page. Offline is a platform
+  capability whose vocabulary belongs on the sync engine that owns the queue, the
+  conflict policy and the cache, and that engine does not exist. Whichever of them
+  earns real product pull returns **with** its own vocabulary and its executor.
+
+  FROM → TO:
+
+  | removed                                                                                                                                                                | what to do instead                                                                                                                     |
+  | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
+  | `TouchTargetConfig` / `GestureConfig` / `TouchInteraction` / `SwipeGestureConfig` / `PinchGestureConfig` / `LongPressGestureConfig` / `GestureType` / `SwipeDirection` | nothing to author — touch targets and gesture handling are the component library's behaviour                                           |
+  | `DndConfig` / `DragItem` / `DropZone` / `DragConstraint` / `DragHandle` / `DropEffect`                                                                                 | nothing to author — drag-and-drop is renderer behaviour                                                                                |
+  | `KeyboardNavigationConfig` / `KeyboardShortcut` / `FocusManagement` / `FocusTrapConfig`                                                                                | nothing to author — focus order and shortcuts are renderer behaviour                                                                   |
+  | `ComponentAnimation` / `MotionConfig` / `PageTransition` / `TransitionConfig` / `TransitionPreset` / `EasingFunction` / `AnimationTrigger`                             | nothing to author. (For theme-level CSS variables see `theme.customVars`; the theme `animation` block was separately retired at #5021) |
+  | `OfflineConfig` / `OfflineCacheConfig` / `SyncConfig` / `OfflineStrategy` / `ConflictResolution` / `PersistStorage` / `EvictionPolicy`                                 | nothing to author — offline sync is unimplemented; its vocabulary arrives with the sync engine                                         |
+
+  **No metadata document needs editing.** A stack that parsed before parses
+  byte-for-byte the same after: none of these blocks was writable in the first
+  place. The break is a TypeScript one — every removed name is `TS2305` on
+  `@objectstack/spec` and `@objectstack/spec/ui` after upgrade.
+
+  One name is worth checking explicitly: the bare **`ConflictResolution`**. #4738
+  renamed the connector-side enum to `ConnectorConflictResolution` _because_
+  `ui/offline.zod.ts` owned the bare name; that owner is now gone, so the bare name
+  is published by **nobody**. The #4738 rename stands — freeing a word is not a
+  reason to spend a second breaking change renaming back — and no domain re-adopts
+  it. If you consumed it as a type for your own offline code, declare that union
+  locally; it is your client's policy, not the platform's.
+  `@objectstack/spec/integration`'s `ConnectorConflictResolution` (connector sync)
+  and `@objectstack/spec/api`'s `ConflictResolutionStrategy` (route merge policy)
+  are different concepts and are untouched.
+
+  ⚠️ `ui/animation.zod.ts` (`ComponentAnimation` / `MotionConfig` /
+  `PageTransition` / `AnimationTrigger`) is a **different surface** from the theme
+  `animation` block retired by #5021 — different file, different defs, different
+  manifest entries. That one had a carrier key and got a `retiredKey()` tombstone;
+  this one had none and gets deletion.
+
+  The retirement kit:
+
+  - **No `retiredKey()` tombstone, deliberately** — route 3 of the retirement
+    playbook ("nothing parses it → neither"), as used by #4834 / PR #4878 (kernel
+    plugin-runtime family) and #4938 / PR #5293 (`HttpServerConfig`). A tombstone
+    is a message to whoever writes the key; with no carrier key there is no shape
+    for one to sit on and no author who could ever receive it.
+  - **No ADR-0087 D2 conversion**, for the same reason: measured **zero** authored
+    instances in `examples/**` and `apps/**` — necessarily zero, since the keys
+    were unwritable — so there is no source for the chain to rewrite. The
+    registered record is the **D3 `SemanticMigration`**
+    `ui-interaction-config-family-retired`, with the protocol-17 step's rationale
+    extended.
+  - **Whole-file deletion was checked per file, not assumed.** Each of the five
+    was verified to have no surviving export with a live consumer (the #4938
+    lesson: retire the shapes, keep the file when a sibling is alive). All 64
+    names were in-family and unreachable, so all five files go.
+  - Baselines updated deliberately: `json-schema.manifest.json` (−32, the #2978
+    ratchet fires first and demands each deletion), `authorable-surface.json`
+    (−109, adjudicated by the #4650 gate's path 3 "def no longer emitted by this
+    build"), `api-surface.json` (−64). Reference docs, `references/ui/meta.json`
+    and the strictness-ledger counts regenerated.
+  - **Pins are bidirectional.** `ui/interaction-config-retirement.test.ts` asserts
+    absence across every public entry by resolved symbol identity _and_ the
+    survival of the neighbours a too-wide sweep would take — first among them
+    `ResponsiveConfigSchema`, batch 13's sixth file, which measured **reachable**
+    (`page.components[].responsive`) and was tightened rather than retired.
+
+  No runtime behaviour changes. That impossibility is the reason for the removal.
+
+- c87ef70: Close nine authorable automation shapes against unknown keys (#4001 batch 11, ADR-0078)
+
+  zod's default is `.strip`: a key a schema does not declare is silently discarded
+  and the parse still succeeds. On an authoring surface that is the worst failure
+  mode — the author (increasingly, an AI) gets a success envelope and ships
+  metadata that quietly ignores what they wrote. This batch closes the nine
+  remaining shapes in `automation/`'s main body.
+
+  **BREAKING.** Each of these now raises a named, fixable error instead of dropping
+  the key. The rejection carries the surface, the offending key, and — where the
+  word is recognisable — the canonical spelling.
+
+  **`flow.zod.ts` — the six NESTED blocks.** The four outer shapes (flow / node /
+  edge / variable) were closed earlier; their inner blocks were not, so the gate
+  rejected `nodee:` at node level while `connectorConfig: { connectorID }` — one
+  capital letter — parsed clean and dispatched the action against an undefined
+  connector id. Now strict: `FlowNode.connectorConfig`, `.position`,
+  `.inputSchema` (each parameter declaration), `.waitEventConfig`,
+  `.boundaryConfig`, and `Flow.errorHandling`.
+
+  Renames the rejections offer, each one a real spelling of the same knob on a
+  neighbouring surface in this repo:
+
+  | you wrote                                                         | write instead                                | where the other word comes from                   |
+  | ----------------------------------------------------------------- | -------------------------------------------- | ------------------------------------------------- |
+  | `connectorConfig.params` / `parameters` / `arguments` / `payload` | `input`                                      | script-node `config.inputs`, integration products |
+  | `waitEventConfig.event` / `signal` / `duration` / `delay`         | `eventType` / `signalName` / `timerDuration` | —                                                 |
+  | `boundaryConfig.attachedToRef` / `cancelActivity`                 | `attachedToNodeId` / `interrupting`          | BPMN 2.0's own attribute names                    |
+  | `errorHandling.backoffMs`                                         | `retryDelayMs`                               | `shared/retry-policy.zod.ts` (#4661)              |
+  | `errorHandling.initialDelayMs` / `maxDelayMs`                     | `retryDelayMs` / `maxRetryDelayMs`           | connector `RetryConfig`                           |
+  | `errorHandling.retries` / `attempts` / `onError`                  | `maxRetries` / `strategy`                    | —                                                 |
+
+  Two are prescriptions rather than renames, because a rename would be wrong:
+  `inputSchema`'s `optional` is the opposite polarity of `required` (write
+  `required: false`), and `errorHandling.maxAttempts` counts the first attempt
+  while `maxRetries` counts the ones after it (write `maxRetries: maxAttempts - 1`).
+
+  **Deliberately still open**, both now pinned in code and in tests so a later
+  sweep stops rather than "finishing" the file: the flow node `config` slot
+  (ADR-0018 — the plugin node-type namespace, owned by each executor's
+  `configSchema`) and `FlowVersionHistorySchema` (emitted on publish, never
+  authored; the flow _inside_ a history record is still gated by `FlowSchema`).
+
+  **`time-relative-trigger.zod.ts`.** `config.timeRelative` sits under the open
+  node `config` slot, so this schema is the only key gate it has — and it is
+  `safeParse`d at BIND time, not only at authoring. `{ …valid, offsetDay: 7 }`
+  used to bind a sweep that ran daily with the author's narrowing discarded, and
+  reported itself configured; it now refuses to bind and says why. `field` →
+  `dateField`, `filters` → `filter`, `objectName` → `object`, `limit` →
+  `maxRecords`; `schedule` and `runAs` get pointed at the layer that owns them.
+
+  **`flow-function.zod.ts`.** `{ handler, effect }` in `defineStack({ functions })`.
+  This binds at authoring only — the boot path reads entries with
+  `normalizeFlowFunctionEntry`, not a parse — which is exactly why it matters:
+  that reader takes two keys and ignores the rest by construction, so a misspelled
+  `effect` was dropped at the schema and then not looked for. The function still
+  registered, still ran, and its writes were still counted as none, keeping
+  #4354's broken-sweep query silent on the one run that needed it.
+
+  **`webhook.zod.ts`.** `object_name` → `object` and `active` → `isActive` (the
+  `sys_webhook` column names, for anyone re-authoring from a row), `events` →
+  `triggers`, `endpoint` → `url`; the five props #3494 removed now reject with
+  their reason instead of vanishing. Strictness also rides `.extend()` onto the
+  connector `WebhookConfigSchema`.
+
+  **`webhook` also gains the ADR-0010 protection envelope** (`protection`, plus
+  the loader-set `_lock` / `_lockReason` / `_lockSource` / `_provenance` /
+  `_packageId` / `_packageVersion` / `_lockDocsUrl`). This is not a separate
+  feature: both metadata load paths call `applyProtection` on every type, so a
+  package-loaded webhook already carried those keys when `plugin-webhooks`
+  re-parsed it at boot. Closing the shape without declaring them would have turned
+  every package-shipped webhook into a skipped subscription after a redeploy.
+
+- 3cb0618: feat(spec)!: reject unknown keys on the ETL authoring contracts (#4001 批 12)
+
+  The final `automation/` wave of the 2026-08-03 "necessary-and-complete" ruling.
+  Seven strip sites in `automation/etl.zod.ts` close, and `automation/`'s
+  remaining-strip count drops 53 → 46 (authorable 27 → 20).
+
+  Now strict: `ETLSourceSchema` (and its `incremental` block),
+  `ETLDestinationSchema`, `ETLTransformationSchema`, `ETLPipelineSchema` (and its
+  `retry` and `notifications` blocks).
+
+  **Deliberately still open: `ETLPipelineRunSchema`, `.stats` and `.error`.**
+  Every key on those is a fact the engine produces about a run that already
+  happened — an id it minted, a status it reached, counters it accumulated.
+  Nobody authors a run result, so strictness buys no author protection there,
+  while it would turn a future engine reporting one more counter into a parse
+  crash for every existing reader. Same disposition, same reason, as
+  `FlowVersionHistorySchema` and all of `execution.zod.ts`.
+
+  **Migration.** Every key now rejected was previously stripped and had no
+  runtime effect, so removing or renaming one never changes behaviour. No
+  ADR-0087 conversion is needed: the three shipped example apps' built artifacts
+  were walked (3930 nodes) with 0 shapes newly rejected, the probe proven red
+  first on an injected control, and all three `objectstack validate` runs pass.
+
+  The rejections carry their own prescriptions:
+
+  - **source / destination / transformation**: the common mistake here is not a
+    typo but a MISPLACEMENT. `table`, `schema`, `endpoint`, `path`, `format`,
+    `condition`, `groupBy` are real settings that belong one level down, inside
+    the open `config` record; every message on these three surfaces says so.
+  - `source.incremental`: `timestampField` → `cursorField` (the connector layer's
+    `DataSyncConfig` spells the same thing `timestampField`).
+  - `destination`: `strategy` → `writeMode`; on the **pipeline** the same word is
+    `strategy` → `syncMode`. The connector's one `strategy` enum
+    (`full | incremental | upsert | append_only`) splits across those two keys —
+    the write half on the destination, the extraction half on the pipeline.
+  - pipeline `direction`: not a key at all, by design. An ETL pipeline states
+    direction structurally, by which endpoint is `source` and which is
+    `destination`; to reverse one, swap the two endpoints.
+  - `retry`: `maxRetries` → `maxAttempts`, and `retryDelayMs` → `backoffMs` (the
+    pre-17 spelling retired in #4661). `backoffMultiplier`, `maxRetryDelayMs` and
+    `jitter` are declared on the converged `RetryPolicySchema` and **deliberately
+    absent** here — a documented absence, not a typo. Converging the two retry
+    vocabularies is tracked as #4962.
+  - `notifications`: `onError` → `onFailure`.
+
+  **One published-artifact change, not a no-op.** The campaign's standing claim
+  that strictness does not move the published JSON Schema holds per direction:
+  `build-schemas.ts` prefers `io: 'output'`, where a stripping object already
+  emits `additionalProperties: false`. `ETLPipelineSchema` is the case where that
+  does not apply — it cannot convert in output mode at all (`schedule` is
+  `CronExpressionInputSchema`, a transform), so the build falls back to input
+  mode, and there strip emits nothing while strict emits
+  `additionalProperties: false`. The published pipeline schema therefore narrows
+  from "unspecified" to "closed", which is the intended direction — the
+  publication now matches the parse instead of being quieter than it.
+  `ETLPipelineRun` publishes under output mode and did not move.
+
+- 32a0874: feat(spec)!: reject unknown keys on the flow-node config contracts (#4001 批 9)
+
+  The first `automation/` wave of the 2026-08-03 "necessary-and-complete"
+  ruling. Fourteen strip sites across three files close, and `automation/`'s
+  remaining-strip count drops 67 → 53 (authorable 41 → 27).
+
+  - **`automation/io-node-config.zod.ts`** — `NotifyConfigSchema`,
+    `HttpConfigSchema`.
+  - **`automation/builtin-node-config.zod.ts`** — the CRUD quartet
+    (`get_record` / `create_record` / `update_record` / `delete_record`),
+    `ScreenConfigSchema`, `ScreenFieldConfigSchema` and its `options` item,
+    `MapConfigSchema`.
+  - **`automation/schemaless-node-config.zod.ts`** — `ScriptConfigSchema`,
+    `SubflowConfigSchema`, `DecisionConfigSchema`, `DecisionConditionSchema`.
+
+  The deliberately-open `FlowNodeSchema.config` SLOT is unchanged — ADR-0018
+  keeps `node.type` open so plugins contribute their own executors, and closing
+  the slot would close that extension point. What is closed is the per-node-type
+  contract _inside_ it.
+
+  **Why the third file is different.** `registerFlow()` already hard-rejects
+  undeclared config keys against a node's descriptor `configSchema` (#4277), and
+  `script` / `subflow` / `decision` publish no descriptor `configSchema` — so
+  that walk skips them by construction. Until now those three had **no**
+  unknown-key enforcement at any layer. For them this is the first gate, not a
+  second one.
+
+  **Migration.** Every key now rejected was previously stripped and had no
+  runtime effect, so removing or renaming one never changes behaviour. All three
+  shipped example apps were re-validated after the change and no stored shape
+  needed an ADR-0087 conversion (160 flow nodes walked, 52 carrying one of these
+  contracts, 0 rejections). The rejections carry their own prescriptions:
+
+  - `notify`: `to` → `recipients`, `subject` → `title`, `body` → `message`,
+    `url` → `actionUrl`, `source: { object, id }` → `sourceObject` + `sourceId`.
+  - CRUD: `object` → `objectName`, `filters` → `filter`,
+    `fieldValues` → `fields`, `recordId` → a filter VALUE
+    (`filter: { id: '{record.id}' }` — no CRUD executor has ever read a
+    `recordId` key), and on `update_record` / `delete_record` `outputVariable`
+    is a documented absence, not a typo — read the row back with a following
+    `get_record`.
+  - `screen`: `object` → `objectName`, and on a field item
+    `visibleIf` → `visibleWhen`.
+  - `map` / `subflow`: `flow` → `flowName`. `subflow`'s `timeoutMs` belongs on
+    the NODE (`FlowNodeSchema.timeoutMs`), not in its config.
+  - `script`: `functionName` → `function`, `input` → `inputs` (the singular
+    stays canonical on `connector_action`'s `connectorConfig.input` — do not
+    "fix" that one). The five `actionType`-branch keys keep their existing
+    `retiredKey()` tombstones.
+  - `decision`: `config.condition` (singular) is **not** renamed to
+    `conditions`. Nothing reads it on a decision — it is the trigger gate on a
+    `start` node and inert everywhere else (#4414) — and declaring branches here
+    _and_ on the out-edges is the double-declaration #4414 was filed for.
+    Branching lives on the out-edges. On a decision BRANCH the predicate slot is
+    `expression`, so `condition` → `expression` there.
+  - decision branch `target`: a VIRTUAL designer column projected from the
+    node's out-edges, never stored — route by matching the branch `label` to an
+    out-edge `label`.
+
+  For a key rewritten at load by an ADR-0087 D2 conversion, reaching this
+  rejection means the config carries BOTH spellings: `renameConfigKey` leaves a
+  shadowed alias in place rather than clobbering the canonical winner, so the
+  retired twin is dead weight and should be deleted.
+
+- 7055c22: Close the responsive/SDUI-styling shapes against unknown keys (#4001 batch 13, ADR-0078)
+
+  zod's default is `.strip`: a key a schema does not declare is silently discarded
+  and the parse still succeeds. On an authoring surface that is the worst failure
+  mode — the author (increasingly, an AI) gets a success envelope and ships
+  metadata that quietly ignores what they wrote.
+
+  **BREAKING.** All four shapes in `ui/responsive.zod.ts` now raise a named,
+  fixable error instead of dropping the key: `ResponsiveConfigSchema`,
+  `ResponsiveStylesSchema`, and the two per-breakpoint maps behind
+  `responsive.columns` / `responsive.order`.
+
+  **What this actually fixes is a nested one.** `PageComponentSchema` has been
+  `.strict()` since ADR-0089 D3a — and that never reached these blocks, because
+  strictness does not recurse. So this component parsed **clean**:
+
+  ```ts
+  PageComponentSchema.parse({
+    type: "element:text",
+    id: "t1",
+    responsiveStyles: { lg: { fontSize: "40px" } },
+    responsive: { colums: { lg: 4 }, hideOn: ["xs"] },
+  });
+  // → { …, responsiveStyles: {}, responsive: {} }
+  ```
+
+  Every styling and layout instruction the author wrote, gone, reported valid — the
+  node renders unstyled and nothing says why.
+
+  **The renames, and where the wrong word comes from.** This file carries TWO
+  breakpoint vocabularies sixteen lines apart on the same page component:
+  `responsiveStyles` uses ADR-0065's desktop-first buckets, `responsive` uses the
+  Tailwind `xs`…`2xl` ramp. Crossing them is not a typo and edit distance cannot
+  bridge it, so the aliases run both ways:
+
+  | you wrote                                      | write instead                 | where the other word comes from                                             |
+  | ---------------------------------------------- | ----------------------------- | --------------------------------------------------------------------------- |
+  | `responsiveStyles: { xs / sm / md }`           | `xsmall` / `small` / `medium` | the sibling `responsive` key's `BreakpointName` ramp                        |
+  | `responsiveStyles: { lg / xl / 2xl }`          | `large`                       | same, folded onto the unconditional base                                    |
+  | `columns: { large / medium / small / xsmall }` | `lg` / `md` / `sm` / `xs`     | the sibling `responsiveStyles` buckets                                      |
+  | `columns: { xxl }`                             | `2xl`                         | the near-miss this file's own test has pinned as invalid since before #4001 |
+  | `responsive: { hidden }` / `{ hideOn }`        | `hiddenOn`                    | objectui's resolved `useResponsiveConfig` result                            |
+
+  Two are prescriptions rather than renames, because a rename would be wrong. A
+  bare breakpoint name at the `responsive` level (`responsive: { sm: … }`) is the
+  legacy breakpoint-keyed shape from the `view.responsive` retired in 17 (#3896) —
+  three keys are plausible targets, so each name gets its own text naming all
+  three. And a `responsiveStyles` bucket written on `responsive` (or vice versa) is
+  a wrong-layer pointer to the sibling key, not a rename.
+
+  `StyleMapSchema` stays **deliberately open** — its key space is every CSS
+  property, not a contract we own — pinned in the schema JSDoc, in a test, and in
+  the #4001 ledger.
+
+  **Nothing in `ui/touch|animation|dnd|keyboard|offline.zod.ts` changed**, and that
+  is deliberate. The ledger scheduled their 22 sites as `authorable (p)`; resolving
+  the `(p)` found no authoring door at all — nothing declares a carrier key for
+  them, a BFS from all 24 metadata-type roots plus `defineStack` never reaches
+  them (with three positive controls passing in the same run), and no `.parse()` on
+  any of them exists in this repo, objectui, or the example apps. `.strict()` is a
+  property of a parse; there is no parse. Retiring them or giving them a carrier is
+  ADR-0049 enforce-or-remove, tracked in #4988 — not a breaking change to spend
+  here.
+
+- 785a748: feat(spec)!: 收紧 action param 选项、公开分享、报表排序、数据集语义层与仪表盘小组件的嵌套未知键（#4001 批 14）
+
+  `ui/` 方向第二波。账本重测记的 11 个 strip 站点，逐个做门测量后：**9 个收紧，2 个改判**。
+
+  ## 破坏性变更 —— 9 个形状不再静默丢弃未知键
+
+  | 形状                                                           | 文件                  | 之前                            |
+  | -------------------------------------------------------------- | --------------------- | ------------------------------- |
+  | `ActionParamSchema.options[]`                                  | `ui/action.zod.ts`    | `{ label, value }` 之外的键被剥 |
+  | `SharingConfigSchema`                                          | `ui/sharing.zod.ts`   | 同上                            |
+  | `ReportSortSchema` · `JoinedReportBlockSchema`                 | `ui/report.zod.ts`    | 同上                            |
+  | `DatasetDimensionSchema` · `DatasetMeasureSchema` · `.derived` | `ui/dataset.zod.ts`   | 同上                            |
+  | `DashboardWidgetSchema.compareTo`（对象分支）· `.layout`       | `ui/dashboard.zod.ts` | 同上                            |
+
+  **升级方式：把被拒的键改成错误信息点名的那个。** 拒绝本身就带处方 —— 它点名面、原样回显写错的键，并在可能时给出规范拼法。没有任何键被移除，也没有任何合法形状变得不合法：这些 schema 接受的键集合完全没变，变的只是「写了别的会怎样」。
+
+  其中四个是 **strict 外壳套 strip 子块** —— 容器早就 strict，但**严格性不递归**：
+
+  - `ActionParamSchema` 自 #3746 起 strict，而它的 `options[]` 条目不是。实测一个带 `color` / `visibleWhen` / `icon` / `disabled` 的选项过 `getMetadataTypeSchema('action')`，出来是 `{"label":"Overload","value":"overload"}` —— 四个键在任何 renderer 看到之前就没了，报告成功。
+  - `DashboardWidgetSchema` 自 ADR-0021 起 strict，而 `compareTo` 的对象分支和 `layout` 不是。
+  - `DatasetSchema` / `ReportSchema` 同理，漏的正是承载语义契约的那几个子形状。
+
+  ### 为什么 `action` 的选项走 strict，而兄弟 `bulk-action` 走 `.passthrough()`
+
+  两边不同是**测出来的，不是照搬的**。#4909 给 bulk-action 选项条目 `.passthrough()` 的两条理由在这里都不成立：那边的 def「left as-authored」逐字到达 grid（中间没有 spec 门），且 objectui 的 `BulkActionParam` 声明了显式 `[key: string]: unknown` 兜底；这边有一道**已经在剥**的门，落点是**封闭**的 `SelectOptionMetadata` 接口。目标词汇封闭，正是「声明」胜过「容忍」的场合。action param 选项是否该讲字段级的逐选项词汇，是独立的能力问题（#5016），不在本批猜。
+
+  ## 两个形状改判为第四类 `no door`，**不**收紧
+
+  `NotificationActionSchema`（`ui/notification.zod.ts`）与 `EmbedConfigSchema`（`ui/sharing.zod.ts`）**没有授权门**：没有承载键、从 24 个 metadata-type root + `defineStack` 做 BFS（6860 节点）不可达、三个仓里除自测外零 `.parse()`。收紧它们会花掉一次破坏性变更去留下「一个被精确校验的死槽位 —— 更有说服力的谎言」。ADR-0049 定去留：#5015。
+
+  `ui/sharing.zod.ts` 是账本第一个**一行两判**的文件：同一文件里 `SharingConfig` 是活门（`FormViewSchema.sharing` 承载，`rest-server.ts` 靠 `sharing.allowAnonymous` + `sharing.publicLink` 挂匿名表单路由，两个示例应用都在写），`EmbedConfig` 没有门。按文件下判断，无论落哪边都会错一半。
+
+  ## 策展依据是同仓的兄弟契约，不是编辑距离
+
+  - **dataset** 锚在本模块自己 header 点名的 `data/analytics.zod.ts` Cube 层：Cube metric 的 `type` **就是**聚合函数，所以 `{ name: 'revenue', type: 'sum', field: 'amount' }` 过去 parse 干净、算出来是 `count`。`sql` 只给 guidance 不给别名 —— 把 `SUM(amount)` 指向吃字段路径的 `field`，是本战役自己要消灭的那种错误处方。
+  - **report** 的排序键是作者会遇到的**第三种** sort 拼法（`SortNodeSchema` 的 `{field, order}`、小组件的扁平 `sortBy`/`sortOrder`、这里的 `{by, direction}`），而且映射方向相反，任何一种都推不出来。
+  - **dashboard `layout`** 锚在 React-Grid-Layout：`minW`/`static`/`i` 等给逐键 guidance，而不是改名到无关的位置键上。
+  - **sharing** 的别名全是 camelCase 目标，兜底系统性够不着（#4990）。`allowAnonymous` 写错拼法的后果是**表单保持私有而作者以为公开**。
+
+  ## 已知触及面限制（实测记录，非推断）
+
+  `compareTo` 是 union。zod 把失配 union 折叠成一条顶层 `invalid_union`（message 是裸的 `Invalid input`），分支错误挂在 `issue.errors`，而 `zodIssuesToFields` 只映射顶层 —— **处方产生了但送不到作者手上**。拒绝不受影响，这仍是 #4001 的收益。传输缺陷是 #5014，影响本战役放进 union 分支的每一条策展文案。测试对这两半**分开** pin，免得一个绿测试冒充一条没人打印的消息。
+
+- 3af0354: **未知键收紧:`ui/theme.zod.ts` 全部 14 个站点 + `ui/chart.zod.ts` 5 / 7 个站点(#4001 批 15)**
+
+  作者写进主题和图表配置里的未声明键,过去被 zod 默认的 `.strip` 静默丢弃、解析照常成功。现在是一条点名该键、并在能识别时给出正确拼法的报错。
+
+  **先测门,再收紧。** 两个文件在账本上都标着 `authorable (p)`,`(p)` 是待验证:
+
+  - `theme.zod.ts` —— 门是真的,而且有两道:`stack.zod.ts` 声明 `themes: z.array(ThemeSchema)`(所以 `defineStack()` 在每次启动和 `objectstack build` 时解析每个主题),`defineTheme()` 直接解析一个。从 24 个 metadata-type root 加 `ObjectStackSchema` 做 BFS,文件内每个 schema 都可达。**14/14 收紧。**
+  - `chart.zod.ts` —— 5 个可达(`DashboardWidget.chartConfig` / `ReportChartSchema`),已收紧;**`ChartAggregateSchema` 与 `ChartGroupBySchema` 的 object 分支不可达,故意保持原样**,见下。
+
+  ## 破坏性变更 · 迁移
+
+  以下写法过去被静默接受(键被丢弃),现在报错。括号内是新报错直接给出的处方。
+
+  **主题(`defineStack({ themes })` / `defineTheme()`)**
+
+  | 旧写法                                                                                                                                 | 改成                                                                           |
+  | -------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ |
+  | `colors: { card, foreground, mutedForeground, muted, destructive }`                                                                    | `surface` / `text` / `textSecondary` / `disabled` / `error`                    |
+  | `typography.fontSize: { md }`                                                                                                          | `base`(`borderRadius`/`shadows` 有 `md`,字号阶梯没有)                          |
+  | `typography.fontWeight: { base }`                                                                                                      | `normal`                                                                       |
+  | `animation.timing: { easeIn, easeOut, easeInOut }`                                                                                     | `ease_in` / `ease_out` / `ease_in_out`                                         |
+  | `shadows: { inset }`                                                                                                                   | `inner`                                                                        |
+  | `zIndex: { backdrop, overlay }`                                                                                                        | `modalBackdrop`                                                                |
+  | 顶层 `palette` / `radius` / `shadow` / `animations` / `cssVars` / `extend`                                                             | `colors` / `borderRadius` / `shadows` / `animation` / `customVars` / `extends` |
+  | #3494 删除的 8 个 prop(`spacing` / `breakpoints` / `logo` / `density` / `wcagContrast` / `rtl` / `touchTarget` / `keyboardNavigation`) | 各自带独立墓碑处方;多数指向 `customVars`,`logo` 指向 app 的 `branding.logo`    |
+
+  **图表(dashboard widget 的 `chartConfig` / report 的 `chart`)**
+
+  | 旧写法                                                                   | 改成                                                                                         |
+  | ------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------- |
+  | `chartType`                                                              | `type`(`chartType` 是内部拼写,从来不是作者契约)                                              |
+  | `legend` / `dataLabels`                                                  | `showLegend` / `showDataLabels`                                                              |
+  | `interactions` / `annotation`                                            | `interaction` / `annotations`(同一个块里一个单数一个复数)                                    |
+  | axis 上的 `name` / `label` / `dataKey`                                   | `field` / `title`                                                                            |
+  | series 上的 `field` / `title` / `stackId` / `strokeDasharray`            | `name` / `label` / `stack` / `dashArray`                                                     |
+  | annotation 上的 `from` / `to`                                            | `value` / `endValue`                                                                         |
+  | `interaction.zoom` / `interaction.clickAction`(#3752 已删)               | `brush: true` / `onSegmentClick`、`ReportSchema.drilldown`、widget 的 `options` 袋           |
+  | `width` / `stacked` / `dataset` / `objectName` / `aggregate` / `options` | 都是层级放错,报错点名正确的那一层(`layout.w`、`series[].stack`、widget 自己的键、react prop) |
+
+  ⚠️ **严格性会顺着 `.extend()` 传到 `ReportChartSchema`**(`ChartConfigSchema.extend(...)`)。这是有意的,并有测试钉住:report chart 只是把 `xAxis`/`yAxis` 收窄成 dataset 维度/度量名,不新增键,所以继承的键集正好。
+
+  ## 两个站点故意没收紧
+
+  `ChartAggregateSchema` 和 `ChartGroupBySchema` 的 object 分支**有活的承载键**(react 层 `< ObjectChart objectName aggregate={…} >`,objectui 的 `ObjectChart` 真的读它跑查询),**但没有任何 parse**:两者从所有 metadata-type root 都不可达,三个仓库里除单测外无人 `.parse()`,而唯一审查它的 react 页发布 lint 是手写重推规则、从不检查未知键。
+
+  `.strict()` 是 parse 的属性,这里没有 parse —— 收紧只会让文件看起来完成,并留下*一个被精确校验的死槽位*(#4583)。账本因此新增第四类 **`no gate`**(承载键活、parse 缺),与批 13 的 `no door`(承载键本身不存在)并列:两者处方相反,前者该接闸门,后者该走 ADR-0049 退役。已归档为独立 issue。
+
+  主题里那些**发出后无人读取**的 CSS 变量(`--font-size-*` / `--z-*` / `--duration-*` …)是 ADR-0049 的 liveness 题目,不是未知键题目,同样单独归档 —— 收紧能让被丢弃的键变响,不能让一个槽位变活。
+
+- 866ff16: Close `AriaProps` against unknown keys, and reclassify `widget` + five `i18n` shapes as no-door (#4001 batch 16, ADR-0078)
+
+  zod's default is `.strip`: a key a schema does not declare is silently discarded
+  and the parse still succeeds. On an authoring surface that is the worst failure
+  mode — the author (increasingly, an AI) gets a success envelope and ships
+  metadata that quietly ignores what they wrote.
+
+  **BREAKING — one shape.** `AriaPropsSchema` (`ui/i18n.zod.ts`) now raises a
+  named, fixable error instead of dropping the key. It is carried as `aria:` on
+  roughly thirty live shapes under six metadata-type roots — `ListViewSchema`,
+  `PageSchema`, `PageComponentSchema`, `DashboardWidgetSchema`, `ChartConfigSchema`,
+  `ActionSchema`, and twenty SDUI component defs — so this is the highest-fan-out
+  single site the `ui/` wave has closed.
+
+  **What it was doing.** Through the `view` metadata root, this parsed **clean**:
+
+  ```ts
+  getMetadataTypeSchema("view").parse({
+    listViews: {
+      my_view: {
+        type: "grid",
+        columns: ["name"],
+        aria: { label: "Accounts", describedBy: "accounts-help" },
+      },
+    },
+  });
+  // → aria: {}
+  ```
+
+  Both keys gone, reported valid. The accessible name existed in the source file
+  and nowhere else — a screen-reader user hears the DOM default, and nothing in the
+  toolchain ever said so. Those two spellings are not hypothetical: they are what
+  objectui's `ARIA_KEY_ALIASES` normalizer folds at the `ListView` boundary
+  (objectui#2890), i.e. what stored view metadata actually carries.
+
+  **The renames, each anchored to a named sibling contract.**
+
+  | you wrote     | write instead     | where the wrong word comes from                                                                    |
+  | ------------- | ----------------- | -------------------------------------------------------------------------------------------------- |
+  | `label`       | `ariaLabel`       | objectui's stored legacy spelling, folded by `normalizeListViewSchema`                             |
+  | `describedBy` | `ariaDescribedBy` | same                                                                                               |
+  | `ariaRole`    | `role`            | this shape's own inconsistency — two of its three keys carry the `aria` prefix and `role` does not |
+
+  `arialabel`, `ariaLabell`, `ariadescribedby`, `aria-label` and `roles` are left to
+  the edit-distance fallback, measured before anything was hand-written: an alias
+  for a key the fallback already reaches is transcription, not judgement.
+
+  **Two keys get a prescription instead of a rename**, because renaming them would
+  be wrong (the ledger's finding 7 — this campaign's own fix once signposting the
+  way into the failure it exists to kill):
+
+  - `live` is real and rendered — by objectui's `ListView` alone, which reads
+    `schema.aria?.live` and emits `aria-live`. objectui declares it as
+    `AriaPropsSchema.extend({ live })`, so **that surface keeps accepting it** (and
+    now inherits this error map for everything else). On any other surface the
+    message says where `live` IS valid rather than pointing at a declared key that
+    means something else. Promoting it into the shared shape would advertise
+    `aria-live` on twenty-nine renderers that do not implement it; the promotion
+    question is **#5058**.
+  - `ariaLabelledBy` / `labelledBy` — `aria-labelledby` references another
+    element's id, which is not the same thing as `ariaLabel` (a literal string), so
+    there is nothing to rename it to. The gap is named, and is also #5058.
+
+  **A `.strip()` was added to four files this batch did not otherwise touch.**
+  `animation.zod.ts`, `dnd.zod.ts` (×2), `keyboard.zod.ts` and `touch.zod.ts` build
+  their config shapes as `z.object({…}).merge(AriaPropsSchema.partial())`, and
+  `.merge()` adopts the incoming schema's unknown-key posture — so closing
+  `AriaProps` would have silently closed all five of those shapes too, with zod's
+  generic message and against #4988's measured verdict that nothing parses them.
+  The explicit `.strip()` holds their posture; `i18n.test.ts` pins it.
+
+  **Nothing in `ui/widget.zod.ts` changed, and five of `ui/i18n.zod.ts`'s six
+  shapes were left open** — deliberately, on measurement. The ledger scheduled
+  `widget` as `authorable (p)` / 9 sites and warned that `i18n`'s label shapes were
+  "wide-open records by design"; resolving both found something more specific.
+  `widget.zod.ts` has no authoring door at all: nothing under `packages/spec/src`
+  imports it except the barrel, a BFS from all 24 metadata-type roots plus
+  `defineStack` never reaches it, and no `.parse()` on any of its shapes exists in
+  `objectstack`, `objectui` or `cloud` outside its own tests. The same holds for
+  `I18nObjectSchema`, `PluralRuleSchema`, `NumberFormatSchema`, `DateFormatSchema`
+  and `LocaleConfigSchema`. `.strict()` is a property of a parse; there is no parse.
+  Retiring them or giving them a carrier is ADR-0049 enforce-or-remove, tracked in
+  **#5055** — not a breaking change to spend here.
+
+  The warning about the open record was aimed one level off, and both levels are
+  now recorded: `I18nObject.params` is a `z.record` interpolation bag whose key
+  space is whatever the message template names — openness there is the contract, and
+  it was never a site this ratchet could close. The config block the map assumed was
+  open alongside it (`AriaProps`) turned out to be the directory's most widely
+  carried live shape.
+
+  Zero-breakage evidence: full `@objectstack/spec` suite, `tsc --noEmit`, all ten
+  spec `check:*` gates, `objectstack validate` on app-showcase / app-crm / app-todo,
+  and an ADR-0087 direct-parse probe over the three apps' **built** artifacts —
+  zero `aria` slots present, with the probe's negative control proven red on a
+  legacy-spelled block.
+
+- 5a85e67: **`ui/component.zod.ts` 的 29 个站点判定为 `no gate`,不收紧(#4001 批 17,ADR-0078)**
+
+  ⚠️ **本条没有破坏性变更,没有迁移,没有任何键的行为改变。** 它记录的是一次测量结果:SDUI 组件 props 这块 `ui/` 目录最大的待收紧面,**根本没有 parse**,所以 `.strict()` 在这里不会强制任何东西。
+
+  ## 为什么不收紧
+
+  `.strict()` 是 **parse 的属性**。三条独立测量(2026-08-04,控制组同轮为真):
+
+  1. **承载键活着,但它是个开放口袋。** `PageComponentSchema.properties` 是 `z.record(z.string(), z.unknown())`。`PageComponentSchema` 自 ADR-0089 D3a 起确实是 `.strict()`,但**严格性不递归**——它守住 component 节点自己的键,`properties` 里面完全不校验,也没有任何地方按 `type` 分派 `ComponentPropsMap`。
+  2. **BFS 不可达。** 从 24 个 metadata-type root 加 `ObjectStackSchema` 出发(复用 `build-schemas.ts` 自己的 `zodChildSchemas`/`zodShapeOf`,即 #4650 闭包,6899 个节点),本文件 **52 个目标全部 UNREACHABLE**(21 个导出 schema + `ComponentPropsMap` 全部 31 个条目);同一轮里 `PageSchema` / `PageComponentSchema` / `PageRegionSchema` / `ThemeSchema` / `ChartConfigSchema` / `ResponsiveConfigSchema` 六个正控制组全部 `root-graph`,批 13 的 no-door 形状保持 unreachable。BFS 正好停在 `properties`。
+  3. **三个仓库无生产 parse 点。** `objectstack` / `objectui` / `cloud` 中,对本文件任何 schema 的 `.parse()`/`.safeParse()` 全部落在本文件自己的单测里。objectui 手写平行的 React interface、只引用推断类型;cloud 引用为 0;`react-blocks.ts` 只用 `Object.keys(ComponentPropsMap)` 取类型名。
+
+  经验证据(`definePage()` 就是 `PageSchema.parse()`,活的授权门):example 语料 10/10 个页面上,写进 `components[].properties` 的未声明键**原样通过并被保留**;同一个键放到外面一层(`properties` 的兄弟位)10/10 被拒——这个负控制组才让前一个数字有意义。
+
+  ## `no gate`,不是 `no door` —— 不要退役
+
+  这些词汇是**活的**,不能按 ADR-0049 退役:objectui 的 `SchemaRenderer` 把 `properties` 整个 hoist 到节点上,再把不在固定 deny-list 上的**每一个**作者键 spread 成 React prop。所以拼错的键既不被拒、也不被丢,而是安静地流到渲染器再被忽略——正是 ADR-0078 要消灭的形状,只是位置比本 ratchet 能触及的层更低一层。
+
+  这确实是 #4909 的 open-slot 形状,但在一个没人 parse 的 schema 上,`.passthrough()` 和 `.strict()` 一样空洞,所以**没有改任何 posture**。
+
+  contract-first 的修法是把 parse 接到承载键自己的闸门上,已单独立为 **#5068**;那个 issue 同时记录了两条使它不能顺手做的约束:`type` 是开放 union(`record:line_items` 这类未注册类型在现实中被使用),以及真实页面已经写了这些 schema 未声明的形状(`record:details` 的 `sections[].fields[]`/`hideFields[]`、record picker 的 `labelField`)。#5068 落地后本文件才重新变成 `authorable`,收紧才有意义。
+
+  判定写在三处(文件头、`component.test.ts` 的钉子——含一条 `properties` 一旦获得类型化分派就变红的断言、账本 `ui/` 两张表),改要一起改。
+
+  账本连带效果(与 #5042 批 14、#5069 批 16、#5070 批 18 合并后,从存活行重算):`ui/` 的 authorable strip 从 35 降到 **6 of 75**——重分类只是换类不是出列,总数不变,文件保留 29/29 行,`check:strictness-ledger` 的反向钉子仍然管着它;`no gate` 从 2 涨到 **31**。批 18 关掉 15 个真门、批 17 测出 29 个没有门,两件事叠加后 `ui/` 只剩 **6 个** authorable strip 站点。由此得到这个目录现在最大的一个事实:**`ui/` 剩余 75 个 strip 站点里有 69 个(92%)根本不是本 ratchet 的工作**(38 个 `no door` + 31 个 `no gate`)。排后续 `ui/` 收紧批次前请先读这个数——这个目录的 ratchet 已经接近完成,剩下的绝大多数是别的 issue 的工作。
+
+- c183a12: spec(ui): `userFilters.allowAddTab` 提升进契约,`UserFiltersSchema` 随之收紧 (#5073)
+
+  `UserFiltersSchema` 是 #4001 批 18 在 `ui/view.zod.ts` 留下的最后一块「不是 strictness 问题」的开放形状 —— 挡住它的是一条**能力声明**,不是姿态判断。
+
+  **为什么之前不能直接关。** objectui 的列表渲染器真读 `config.allowAddTab` 并据此渲染「新增 tab」控件(`plugin-list/src/UserFilters.tsx:182` / `:742`),它自己的 `UserFiltersSchema` 也声明了这个键 —— 两边形状的差集恰好只有这一个。而 `saveMetaItem` 用 `safeParse` 校验后**原样存原始 body**(丢弃 `parsed.data`,好让 Studio 的辅助键活过往返),所以被 strip 掉的只是那份被丢弃的解析结果:存储里键还在,渲染器读得到,**这个能力今天是工作的**。直接收紧不是「把静默失效变响亮」,而是把一个已发布、在用的配置变成 422 —— 而且 422 会点名一个作者本来写对了的键,正是本战役 finding 7 的形状(平台权威把作者引向删掉能工作的东西)。
+
+  **裁定与落地(维护者 2026-08-04,选项 A):promote 后收紧,同 PR 完成。** `allowAddTab` 现在**声明**在 `UserFiltersSchema` 上,能力因此可从契约被发现 —— JSON Schema、Studio 的 SchemaForm、AI 作者都看得到,而不是只存在于一个 React 文件里。被否决的是判它为 objectui-only 扩展(`SANCTIONED_LOCAL`):那会让 `packages/spec` 与 objectui 成为同一份契约的两个事实来源,正是 #2231 的 derive-by-reference 统一要消掉的分叉(PD#12)。声明的措辞刻意收窄到渲染器真做的事 —— 它声明「渲染出新增 tab 的入口」,不承诺点击后能创建预设(objectui 那个按钮目前没有 click handler,已另行立案),因为承诺更多就是 PD#10 的「宣传运行时并不交付的能力」。
+
+  ## BREAKING
+
+  **1. `userFilters` 上的未知键从静默丢弃变为拒绝。**
+
+  ```diff
+    userFilters: {
+      element: 'tabs',
+  -   allowAddTabs: true,   // 拼错 → 以前静默消失,现在 422(并提示 → allowAddTab)
+  +   allowAddTab: true,
+    }
+  ```
+
+  FROM → TO:未声明的键 → 删除它,或改成它想表达的那个已声明键。错误信息会点名该键并给出最近的候选。`allowAddTab` 本身**不需要迁移** —— 它现在是合法声明键,原有配置照常通过。
+
+  **2. 对象列表视图(`ObjectUserFiltersSchema`)拒绝 page-only 的三个键:`tabs` / `showAllRecords` / `allowAddTab`。**
+
+  这三个键在对象视图上一直是无效的(`ObjectUserFiltersSchema` 由 `UserFiltersSchema.omit()` 派生,而 `.omit()` 继承基类姿态),此前被静默丢弃 —— 与此同时 CLI lint(`packages/lint/src/validate-list-view-mode.ts`)早就在报同一个配置。两扇门从此一致。
+
+  ```diff
+    // 对象视图:tab 栏的角色已被 ViewTabBar(已存视图切换器)占用
+    listViews: {
+  -   // userFilters: { element: 'dropdown', tabs: [{ name: 'mine', label: '我的' }] }
+  +   mine: { label: '我的', filter: [['owner', '=', '{userId}']] },   // 每个具名视图渲染成一个分段 tab
+    }
+  ```
+
+  FROM → TO:`userFilters.tabs` → 对象的 `listViews` 具名条目;`showAllRecords` → 默认列表视图本身就是「全部记录」入口;`allowAddTab` → 由 ViewTabBar 自带的新增控件承担。三条拒绝各自带 `guidance` 处方,不是裸的 "unrecognized key"。
+
+  派生变体同时改为携带**自己的**错误映射:`.omit()` 会连基类的 `knownKeys` 一起继承,而那份候选列表是从基类形状读的、仍然含被 omit 掉的键 —— 实测在对象视图上写 `tab` 会被答复 _"Did you mean `tab` → `tabs`?"_,把作者指向这个形状唯一拒绝的键。形状仍由 `.omit()` 派生(#2231 不变),候选池改为按 omit 后的形状构建。
+
+- 06df4fa: **View sub-blocks now reject unknown keys instead of dropping them (#4001 批 18).**
+
+  Fifteen object shapes in `ui/view.zod.ts` were still zod's default `.strip`: a key
+  the schema did not declare was discarded and the parse still succeeded, so the view
+  rendered without whatever the key was meant to configure — no error, no warning,
+  `tsc` green. They are now closed, and the rejection names the surface, echoes the
+  offending key, and suggests the right one.
+
+  Closed shapes: `ViewDataSchema`'s four provider arms (`object` / `api` / `value` /
+  `schema`), `UserFilterField.options`, `GanttQuickFilter.options`,
+  `GanttConfig.tooltipFields`, `ListView.conditionalFormatting` / `.emptyState`, the `keyField` block on a form field, `FormView.subforms`, and all
+  four arms of `FormView.submitBehavior`.
+
+  **Migration — the spellings that used to be silently dropped and now raise:**
+
+  | You wrote              | Where                                  | Write instead                                                            |
+  | ---------------------- | -------------------------------------- | ------------------------------------------------------------------------ |
+  | `object`               | `form.subforms[]`                      | `childObject`                                                            |
+  | `objectName`           | `data: { provider: 'object' }`         | `object`                                                                 |
+  | `delay` / `delayMS`    | `submitBehavior: { kind: 'redirect' }` | `delayMs`                                                                |
+  | `visibleWhen` / `when` | `list.conditionalFormatting[]`         | `condition`                                                              |
+  | `description` / `text` | `list.emptyState`                      | `message`                                                                |
+  | `count`                | a user-filter option                   | nothing — counts are computed; set `showCount: true` on the filter field |
+  | `action` / `button`    | `list.emptyState`                      | configure the `addRecord` block instead                                  |
+
+  `submitBehavior` is now a discriminated union on the `kind` literal it already
+  required. No accepted input changes shape; the rejection improves — a plain union
+  reported `invalid_union` with one sub-error per arm, and the useful message did not
+  survive to the CLI (#5014).
+
+  **Not changed, deliberately:** `GanttConfig` / `TreeConfig` stay open at the parent
+  (`.passthrough()`) so renderer-ahead knobs keep reaching plugin-gantt / plugin-tree —
+  only the nested `tooltipFields` entry closed. `ListView.sort` stays open too — the console
+  stamps a UI row `id` into it (`.strip()` on a wire member does NOT recurse, so a
+  closed nested block 422s a console PUT regardless). `UserFiltersSchema`,
+  `ViewItemSchema` and the private `FormFieldBase` also stay open, each for a measured reason recorded
+  in the schema's own JSDoc, in `view-strictness-batch18.test.ts`, and in the `ui/` row
+  of `docs/audits/2026-07-unknown-key-strictness-ledger.md`.
+
+### Minor Changes
+
+- 9fe9c1d: feat(spec): declare the action-body `ctx.session` contract (#5697)
+
+  An action body reads `ctx.session` on every dispatch, and until now **nothing
+  declared it**. `actionContext` is a bare `any` at both dispatch sites
+  (`domains/actions.ts`, `action-execution.ts`), the sandbox seam types
+  `ScriptContext.session` as `unknown`, and the one spec-side mention was an
+  inline literal on `ActionHandlerContext` carrying a `[k: string]: unknown`
+  catch-all. Declared-nowhere, produced-anyway: no schema, no gate, no generated
+  reference page, and nothing the liveness ledger could reach.
+
+  That is how the surface drifted without anyone noticing. Its `roles` key carries
+  `ExecutionContext.positions` — the ADR-0090 D3 vocabulary handed to authors under
+  the one spelling that ADR forbids — while the hook side retired its own
+  `session.roles` at #5050. One platform, one key name, two opposite answers.
+
+  **`ActionSessionSchema` (`@objectstack/spec/ui`) declares that shape as built.**
+
+  ```ts
+  { userId?: string; organizationId?: string; roles?: string[] }
+  ```
+
+  This release changes **nothing about what the runtime produces** — it is phase 1
+  of #5613's contract-first ruling, and declaring current reality is deliberately
+  not the same as endorsing it:
+
+  - `roles` is declared **deprecated** in its `.describe()` and its JSDoc. The
+    rename to `positions`, with a deprecation window and an ADR-0087 semantic
+    migration, is #5613 phase 2. There is deliberately **no `positions` key yet** —
+    minting one before the migration would ship two live spellings of one value.
+  - The schema is **not strict**, matching `HookContextSchema`: this is a runtime
+    shape the platform hands a body, never authored, and closing it would turn a
+    future engine-side enrichment into a parse failure for whoever parses a context
+    they were given.
+
+  Three facts the declaration now states, all of them previously discoverable only
+  by reading the builder:
+
+  - **Absent means the key is absent.** The builder uses conditional spreads, so
+    `'organizationId' in ctx.session` answers `false` — not "present and
+    `undefined`". The hook path's `input.id` on a bulk write is the opposite case
+    (#5668); an `in` test does not port between them.
+  - **No identity envelope yields no session at all** — `undefined`, never `{}`, so
+    a body can tell "no caller" from "an anonymous caller" (#3712). One consequence:
+    `roles` never appears on its own.
+  - **`organizationId` is the blessed name** for the caller's active org; the
+    v11-removed `session.tenantId` alias (#3280 / #3290) does not come back.
+
+  Type-only on the runtime side, no behaviour change: `buildActionSession()` now
+  declares `ActionSession | undefined` instead of `any | undefined`, and
+  `ActionHandlerContext.session` is the schema's inferred type rather than an
+  inline literal with a catch-all. A handler annotated with `ActionHandler` that
+  read an undeclared key off `ctx.session` now gets a compile error naming it —
+  that key was never produced. `ScriptContext.session` deliberately stays
+  `unknown`: it is one seam over both body kinds, and hook and action sessions are
+  different objects.
+
+  The declaration ships with the gate it needed —
+  `packages/runtime/src/action-session-shape-contract.test.ts` executes the real
+  producer and asserts a non-strict parse of the built object returns it
+  **unchanged**, so a key the builder starts producing without declaring here is
+  stripped and the pin goes red.
+
+- d4e0809: feat(spec): `ActionSession` declares `positions` as canonical and deprecates `roles` (#5779)
+
+  The action-body `ctx.session` contract gains `positions`, the ADR-0090 D3 spelling
+  of the caller's position names, and demotes `roles` to a deprecated alias of it.
+  This is the **spec half** of #5613 phase 2, under the maintainer's contract-first
+  ruling ("C skeleton + A semantics"): phase 1 (#5697) declared the shape the runtime
+  already built, and this opens the rename on top of that declaration.
+
+  **What was wrong.** `buildActionSession()` copies `ExecutionContext.positions` into
+  a key spelled `roles` — the one spelling ADR-0090 D3 bans — so an author met two
+  different answers to one key name on one platform: `session.roles` is rejected in a
+  hook (retired in #5050) and live, populated, and load-bearing in an action body.
+  Phase 1 declared that reality without endorsing it and deliberately withheld a
+  `positions` key, because minting a second live spelling with no closing date is the
+  defect rather than the fix. This change mints it **with** a closing date.
+
+  **Migration prescription — do this now.**
+
+  - Read `ctx.session.positions`. It is the canonical key and it carries exactly the
+    array `roles` carried; the rename is a rename, not a semantic change.
+  - `ctx.session.roles` still resolves for the length of the deprecation window and
+    is removed after it, on the path `session.tenantId` already walked (#3280
+    deprecated, #3290 removed in v11). A body still reading it at that point sees
+    `undefined` with nothing to catch the change — which is why the read moves inside
+    the window, not at its close.
+  - Do **not** migrate an access check by renaming it. `roles.includes('admin')`
+    rewritten as `positions.includes('admin')` migrates the defect: neither array is
+    an authorization input. Privilege is judged by the security service, which
+    evaluates capability grants, placements and the derived posture (ADR-0095).
+
+  **Sequencing — the contract leads its producer.** This release ships the contract
+  only. The producer change (`buildActionSession()` emitting both keys, plus the two
+  already-tracked wrong sentences in its docblock) is #5613's runtime half and lands
+  separately. Until it does, a built session still carries only `roles`, so
+  `positions` is meaning-fixed but not yet presence-guaranteed; both keys are
+  optional, which is what lets the declaration lead without breaking anything. A
+  reader that must straddle the seam may read `positions` and fall back to `roles`
+  for the window's duration only — that fallback expires with the alias.
+
+  Additive and non-breaking on its own: adding an optional key rejects nothing that
+  parsed before, and the runtime consistency pin
+  (`packages/runtime/src/action-session-shape-contract.test.ts`) is unchanged and
+  still green.
+
+  The reader-facing announcement is the ADR-0087 semantic migration
+  `action-session-roles-to-positions`, which carries the prescription above and its
+  acceptance criteria into `spec-changes.json`, the generated upgrade guide and the
+  `spec_changes` MCP tool.
+
+- f724f69: feat(spec): ADR-0117 scoped 接受 —— `owning_business_unit_id` 规范名进入登记处并列入公开表单拒收名单 (#4611)
+
+  ADR-0105 D13 的 promotion 工具要求「按子树的 scoping field 回填 `organization_id`」,
+  但没有任何元数据声明「哪个字段承载 BU 归属」。维护者裁定加速 ADR-0117 补上这一层。
+  本次落地**协议决定的名字面**,不含运行时注入。
+
+  - **ADR-0117 定稿为 `Accepted (D1/D3 scoped)`**:仅 D1(`business_unit` 档与
+    `owning_business_unit_id` 记录戳的命名与语义)与 D3(`record.organization_id ==
+BU(owning_business_unit_id).organization_id` 不变量)进入协议;D5、D2 的默认盖章
+    策略、D8 的启用门粒度、D4 的权限位仍为 Proposed,合并本 ADR 不构成对这四项的裁定。
+  - **新增 `SystemFieldName.OWNING_BUSINESS_UNIT_ID`**(`'owning_business_unit_id'`),
+    明确标注 **open-core 暂不注入** —— 该表是**名字登记处而非注入集合**,`tenant_id` /
+    `user_id` / `deleted_at` 是既有的三条同类先例。早登记是为了阻断消费方各造一个
+    `business_unit_id` / `bu_id` / `dept_id`,即 cloud#982 用 `tenant_id`/`org_id`/`space`
+    付过学费的漂移形态。
+  - **`PUBLIC_FORM_SERVER_MANAGED_FIELDS` 新增该名**:它是与 `owner_id` /
+    `organization_id` 同类的归属锚点,一旦盖章,匿名面上被伪造的值会把记录推到别的部门
+    墙后。在列存在**之前**就拒收是零成本且 fail-closed 的;等列上线后再补名单,中间那个
+    版本就是一个带着发布号的洞。
+
+  **本轮刻意不动 `ownership` 枚举。** `packages/objectql/src/registry.ts` 的 `wantOwner`
+  是**排除式**判定(只排除 `'org'` / `'none'`),此刻加入第四个值会让 `business_unit` 档
+  照常注入 `owner_id` —— 与 ADR-0117 D1 表格恰好相反,属 ADR-0049「spec 不得声明运行时
+  不执行的东西」所禁止的形态。因此 `ownership: 'business_unit'` 目前仍被 Zod 响亮拒绝
+  (并列出 user / org / none 三个合法值),这是**正确**行为,已加 pin 钉住,防止后人
+  「顺手补全」。枚举值与其注入实现同 PR 落地。
+
+  **行为变更提示**:若某应用自行声明了名为 `owning_business_unit_id` 的业务字段并将其
+  放在匿名公开表单上,该字段自本版本起不再接受客户端提交的值。本仓内无任何此类声明;
+  ADR-0117 已将该名收为协议保留的系统列名。
+
+- cdfbee2: feat(spec): `api` is a declared metadata kind — `DEFAULT_METADATA_TYPE_REGISTRY` + `BUILTIN_METADATA_TYPE_SCHEMAS` (#5271, part of #5206)
+
+  `api` items were produced, indexed and executed while the spec declared the kind
+  nowhere. Artifact ingest maps `defineStack({ apis })` to `api` metadata
+  (`ARTIFACT_FIELD_TO_TYPE`), the endpoint matcher indexes them
+  (`buildEndpointIndex`), and #5040's executor serves them — but
+  `DEFAULT_METADATA_TYPE_REGISTRY` had no `{ type: 'api', … }` entry and
+  `BUILTIN_METADATA_TYPE_SCHEMAS` had no `api` binding. So
+  `getMetadataTypeSchema('api')` returned `undefined` and `saveMetaItem` took its
+  documented "unregistered type is stored without validation" branch:
+  `PUT /api/v1/meta/api/:name` accepted **any JSON** and answered 200. That is
+  `declared ≠ enforced` read backwards — enforced but **undeclared**.
+
+  Both halves are now declared, which is one fix with two faces:
+
+  - **A body is validated.** The existing 422 `invalid_metadata` path applies to
+    `api` like every other kind, with structured Zod issues naming the offending
+    key. An endpoint with no `target`, or no `type`, is refused instead of stored.
+  - **The type is describable.** `/meta/types` emits a real JSON Schema and a
+    create seed for `api`, so the metadata-admin engine renders a form rather than
+    a raw-JSON textarea, and the entry carries a real label, domain and file
+    patterns instead of the synthesised `label: 'api'`, `filePatterns: []`
+    placeholder a type with no registry row gets.
+
+  **The write door is unchanged.** `allowRuntimeCreate: true` records what the
+  runtime already did: with no static registry entry, both write gates
+  (`isRuntimeCreateAllowed`, `assertAllowed`) fall through to "runtime-creatable",
+  and both name `api` in that comment. `allowOrgOverride` stays `false`, also its
+  effective value today — an endpoint is the publishing package's outward URL
+  contract, and a per-org fork could move `path`, flip `authRequired` or drop
+  `rateLimit` on a URL third parties integrate against. Marking the type code-only
+  instead (`allowRuntimeCreate: false` + `allowOrgOverride: false`) was considered
+  and rejected: it would turn today's 200 into a 403 rather than validate it, and
+  #5086's refusal runs before persistence for drafts too, which would leave
+  #5206 step 2's `publishPackageDrafts` endpoint gate with no draft to gate.
+
+  **`ApiEndpointSchema` gains the ADR-0010 protection envelope, and stays open to
+  unknown keys.** Every registered kind must declare the envelope its loader
+  stamps (`_packageId` / `_provenance`), or it is dropped on every parse; that
+  spread is added. Closing the shape against unknown keys was attempted and
+  **measured to be unsafe**: the same schema parses stored rows as well as
+  authored declarations (`buildEndpointIndex`, `gateApiItemsForPublish`), and a
+  stored row carries the metadata layer's own bookkeeping (`packageId`, `state`),
+  so `strictObject` turned 10 tests in `packages/metadata` red — the load-time
+  backstop excluded endpoints and the publish gate reported a schema error in
+  place of its ADR-0121 D6 verdict. `api` therefore joins `view` on the #4001
+  campaign's `STILL_STRIP` list, with that measurement written into the list's own
+  note, and the real fix (separating the stored envelope from the body at the
+  metadata layer) is filed as #5309 rather than bought by teaching the authoring
+  vocabulary two storage keys.
+
+  **This is a shape check, not a second servability judge.** ADR-0121's rules —
+  the `apps/<namespace>` carve-out (D1/D2), anonymous-requires-an-armed-`rateLimit`
+  (D6), the supported target subset, mapping and policy — stay with
+  `validateApiEndpointDeclarations` / `identityFreeEndpointGateFailure`, which run
+  at publish and again at load. A pin test asserts an anonymous unmetered endpoint
+  parses green here and is still refused by the gate, so the two never grow
+  competing opinions.
+
+  **Upgrade note (not purely additive).** A stored `api` row that does not satisfy
+  `ApiEndpointSchema` is refused with 422 on its **next write**; reads and the
+  existing load-time behaviour are unchanged (the matcher already excluded
+  unparseable rows loudly, #5189). Every `api` declaration reachable in this repo
+  — the two E8-migrated showcase endpoints and the two dogfood policy-fixture
+  endpoints — was parsed against `ApiEndpointSchema` before landing this: all four
+  clean. A live deployment's `sys_metadata` cannot be scanned from CI; an operator
+  holding hand-written `api` rows should run `GET /api/v1/meta/diagnostics?type=api`
+  (which now covers the type) before upgrading.
+
+  ADR-0088's admission test is satisfied on all three clauses: independent
+  lifecycle (the matcher indexes and invalidates one item at a time), declarative
+  governability (`allowRuntimeCreate` plus file patterns), and a real consumer
+  (#5040's executor, boot-proven by #5040 E8). This does not reverse the `router`
+  kind's retirement — `router`'s delivered forms are code contributions, whereas a
+  single `ApiEndpoint` is a declarative artifact, exactly the "third, real
+  delivered form" ADR-0088's own `router` row anticipated.
+
+- ddc2527: fix(approvals): the ADR-0044 revise window is a service-owned node type, not a bare `wait` (#3823)
+
+  #3801 gated `POST /api/v1/automation/:name/runs/:runId/resume` on the **node type**
+  that produced the suspension: an `approval` pause declares
+  `resumeAuthority: 'service'`, so it continues only through `ApprovalService`.
+  ADR-0044's **revise window** was the same trust boundary in a shape that key
+  could not see. Send-back parked the run on an ordinary `wait` node the flow
+  author placed — correctly `resumeAuthority: 'any'`, because a signal wait is
+  _meant_ to be resumable by an external producer — and `ApprovalService.resubmit`
+  was the only thing that checked anything about continuing it.
+
+  Demonstrated (not reasoned) against the real engine: a raw `resume(runId)` with
+  an **empty body**, from any caller, walked the `resubmit` back-edge into the
+  approval node and opened round N+1 with **no submitter check and no `resubmit`
+  audit row** (`['submit','revise']` — no third row, ever). Worse, when another
+  request was already pending on the record — the exact case `resubmit` refuses
+  with `DUPLICATE_REQUEST` _specifically to keep the run alive_ — the raw resume
+  went around that guard: the approval node's re-entry failed **after** the engine
+  consumed the suspension, and the run was **permanently destroyed** with its
+  round-N request stuck `returned` and no resubmit able to reach it.
+
+  The revise pause is therefore its own node type:
+
+  - **`approval_revise`** (`APPROVAL_REVISE_NODE_TYPE`), registered by
+    `@objectstack/plugin-approvals` alongside the `approval` node, declaring
+    `resumeAuthority: 'service'`. It stays a first-class box on the canvas, in the
+    run log and in the suspended-run store — only the _reuse_ of `wait` was wrong.
+    It takes **no config**: the window ends on the submitter's explicit resubmit,
+    never on a signal or timer. The `resumeAuthority` gate itself is unchanged.
+  - `sendBack` refuses a `revise` edge whose target is not an `approval_revise`
+    node, **before any mutation** (like the existing missing-`revise`-edge check),
+    so no run can be parked in a window something else can advance.
+  - New gating lint `flow-approval-revise-target-not-service-owned`
+    (severity `error`, on `os build` / `os validate` / `os lint` and the runtime
+    metadata publish gate) rejects the old shape at authoring time.
+
+  **Upgrading a flow authored against the original ADR-0044 D3.** One token:
+
+  - **FROM:** `{ id: 'wait_revision', type: 'wait', waitEventConfig: { eventType: 'signal', … } }`
+  - **TO:** `{ id: 'wait_revision', type: 'approval_revise' }` — drop
+    `waitEventConfig` / any `config`; the window has no event to wait on.
+
+  Until you do, such a flow keeps registering and running and its approvals stay
+  decidable (`approve` / `reject` / `recall` / `reassign` are untouched), but
+  **send-back is refused** with a message naming the node and this fix, and
+  re-publishing it reports the lint error. A run _already parked_ in a legacy
+  revise window keeps its recorded node type (a republish never re-types a live
+  pause) and is drained by `resubmit` or `recall` as usual.
+
+  ADR-0044's 2026-07-28 amendment records the reversal of its D3 and of its
+  `Alternatives` rejection of a service-owned revise pause, with the evidence
+  above; the implementation section there records what shipped, why the approval
+  node does not re-suspend itself instead, and why no ADR-0087 conversion was
+  added for the old shape.
+
+- 2e284b2: fix(spec): stop silently stripping widget config off a bulk-action param option (#4001)
+
+  `BulkActionParamSchema`'s `options[]` entry is now `.passthrough()`, matching its
+  parent. **Behaviour change, loosening only**: keys other than `label` / `value` on
+  an option used to be _removed at parse_ and are now preserved. Nothing that parsed
+  before stops parsing, and no key changes meaning — an authored option simply keeps
+  what it was written with.
+
+  Concretely, this used to happen without a warning:
+
+  ```ts
+  // authored
+  options: [
+    { label: "In Review", value: "in_review", color: "#8B5CF6", icon: "eye" },
+  ];
+  // parsed, BEFORE
+  options: [{ label: "In Review", value: "in_review" }];
+  ```
+
+  `color` and `icon` are not decoration the renderer ignores. objectui's
+  `bulkParamToField` spreads every option entry into the field metadata
+  (`packages/plugin-grid/src/components/bulkParamToField.ts:131`), where the widget
+  vocabulary is `SelectOptionMetadata` (`packages/types/src/field-types.ts:288`) —
+  `color`, `icon`, `disabled` and `visibleWhen` beyond the declared pair, and read
+  (`option?.color`, `packages/fields/src/index.tsx:1089`). So the strip deleted
+  config that would otherwise have rendered, on the authoring side, invisibly.
+
+  Nothing to migrate. If you dropped option colors/icons because "the spec ate them",
+  they work now. The strictness ledger's prose already described this level as
+  deliberately open while only the parent schema said so in code; the code now says
+  it too, which is the part a machine can check.
+
+- 0161c7f: feat(spec,lint): declare the chart segment drill — `ChartDrillDownSchema`, on the react tier where it is actually read (#5022)
+
+  `drillDown` has driven a real capability since long before this release: click a
+  bar or a slice on an `<ObjectChart>` and objectui opens the underlying records,
+  filtered by the clicked category, in a drawer. The protocol declared it
+  **nowhere**. objectui read it as `(schema as any).drillDown`, so every key inside
+  it — right, wrong, or misspelled — reached the renderer unchecked, and a typo was
+  simply ignored at click time. This is Prime Directive #10 inverted: not declared
+  without being delivered, but delivered without ever being declared.
+
+  It is declared now, as `ChartDrillDownSchema`, and it is **additive** — nothing
+  that parsed before stops parsing.
+
+  ## What you can write
+
+  `drillDown` is a prop on the react-tier `<ObjectChart>` block:
+
+  ```jsx
+  <ObjectChart
+    objectName="opportunity"
+    aggregate={{ function: "sum", field: "amount", groupBy: "stage" }}
+    drillDown={{ columns: ["name", "amount"], maxRows: 50 }}
+  />
+  ```
+
+  | key       | type                      | meaning                                                                                                                                            |
+  | --------- | ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
+  | `enabled` | `boolean`                 | Only needed to force the drill OFF — the block being present already means on, so `drillDown={{}}` enables it                                      |
+  | `filter`  | `Record<string, unknown>` | Filter for the drilled list; values support `${event.*}`. Omit it and the filter is derived from `aggregate.groupBy` equal to the clicked category |
+  | `title`   | `string`                  | Drawer/dialog heading; supports `${event.*}`                                                                                                       |
+  | `target`  | `'drawer' \| 'dialog'`    | In-place side sheet (default), or a centered modal when the chart is already inside a drawer                                                       |
+  | `columns` | `string[]`                | Column whitelist for the drilled list                                                                                                              |
+  | `maxRows` | `number`                  | Rows per page in the drilled list                                                                                                                  |
+
+  Every one of those six is a key objectui's `ObjectChart` was measured to read.
+  The renderer's own drill type is wider — it is shared with the table / pivot /
+  metric widgets — and the extra keys are **deliberately not declared**, because a
+  chart reads none of them:
+
+  - **`mode`** (`'filter'`/`'record'`) is a table/pivot/metric key. A chart segment
+    is always an aggregate, so there is nothing to discriminate.
+  - **`report`** (drill into a report instead of a record list) is a metric/pivot
+    capability.
+  - **`view`** and **`sort`** are read by _no_ renderer at all (objectui#3354).
+  - **`target: 'navigate'`** is implemented for the other widgets but not for a
+    chart, which falls back to the drawer.
+
+  Writing any of them is now a loud rejection that says which surface owns it,
+  rather than a value that silently does nothing.
+
+  ## Where it is NOT declared, and why that is deliberate
+
+  **Not on `ChartConfigSchema`, and not a dashboard widget key.** A dashboard
+  widget has no per-widget drill configuration, by design: an ADR-0021
+  dataset-bound widget drills through the semantic layer, deriving the target
+  object and filter from the dataset row that was clicked. That is what
+  `content/docs/ui/dashboards.mdx` has said all along, and it is what the renderer
+  does — `DashboardRenderer` never reads `chartConfig`, and `DatasetWidget`
+  forwards exactly one key out of it (`showLegend`). Declaring the drill there
+  would have produced authorable metadata that parses clean and never reaches a
+  renderer — the failure this campaign removes elsewhere.
+
+  So the three places an author might reach for it now answer instead of shrugging:
+
+  - `widget.chartConfig.drillDown` → rejected, pointing at the react-tier prop.
+  - `widget.drillDown` / `widget.drilldown` → rejected, explaining that dashboard
+    drill-through is **automatic**, and naming both configurable drills.
+  - `report.drillDown` → rejected, pointing back at the chart prop.
+
+  ## `drillDown` is not `drilldown`
+
+  Two capabilities, one letter apart, and they are now disambiguated in both
+  directions at the schema gate:
+
+  |          | `drillDown`                | `drilldown`                                     |
+  | -------- | -------------------------- | ----------------------------------------------- |
+  | spelling | camelCase                  | all lowercase                                   |
+  | type     | configuration object       | boolean                                         |
+  | surface  | react `<ObjectChart>` prop | `ReportSchema` key (ADR-0021 D2, on by default) |
+
+  Edit distance alone gets this wrong — the two spellings are a distance of 1, so a
+  plain "did you mean" would happily send an author writing `drillDown` on a report
+  to `drilldown`, where their config object then fails a second time as a boolean.
+  Both gates name the **type** difference, not just the spelling.
+
+  ## Enforced, not just declared
+
+  `@objectstack/lint`'s react-page publish gate now **parses** the schema
+  (`react-chart-drilldown-invalid`) against a static `drillDown={{…}}` literal,
+  rather than re-deriving the rules. Unknown keys, the wrong `target`, and the
+  near-key spelling all fail the build with the schema's own prescription. A value
+  assembled from React state is skipped, unchanged: an unresolvable binding is not
+  a wrong one (ADR-0072 D1).
+
+- e900015: feat(spec): `drillDown.target` 补上 `'navigate'` —— 渲染器已经兑现的第三个 arm (#5435)
+
+  `<ObjectChart drillDown={{ target }}>` 现在接受 `'navigate'`,联合从
+  `'drawer' | 'dialog'` 扩成 `'drawer' | 'dialog' | 'navigate'`。**纯 additive**:
+  之前能解析的一律照旧解析。
+
+  ## 为什么现在才加
+
+  #5022 当初把 `'navigate'` 排除在外,依据是一条**测量**而不是设计偏好 ——
+  当时 objectui 的 `ObjectChart` 自绘抽屉只分支 `'dialog'`,`'navigate'` 会静默
+  落进 Sheet。声明一个渲染器不兑现的值,等于用协议承诺一次永远不会发生的跳转。
+
+  objectui#3382 把这条测量改掉了:`ObjectChart` 现在真正兑现 `'navigate'`,语义
+  对齐 `DrillDownDrawer.navigateOnly` —— 也就是 table / pivot / metric 三个 widget
+  在共享的 `DrillDownConfig` 上一直以来的行为。测量失效,联合随之跟上。
+
+  顺序不可颠倒:**先有渲染器兑现,协议才声明**。在此之前(objectui#3382 合并前)
+  拒绝 `'navigate'` 是正确的。
+
+  ## 写法与兑现条件
+
+  ```jsx
+  <ObjectChart
+    objectName="opportunity"
+    aggregate={{ function: "sum", field: "amount", groupBy: "stage" }}
+    drillDown={{ target: "navigate" }}
+  />
+  ```
+
+  - `'drawer'`(默认)—— 就地侧边抽屉;
+  - `'dialog'` —— 居中模态,适合图表本身已经在抽屉里、再叠一层 Sheet 会很别扭的场合;
+  - `'navigate'` —— **跳过就地视图**,直接打开该对象的完整列表页,带上抽屉本会用的
+    同一套过滤条件(widget filter ∧ 点击段的上下文)。适合「钻取结果是目的地」而不是
+    「瞄一眼」的场景。
+
+  `'navigate'` 是唯一带 **host 前提**的 arm:宿主应用必须提供 drill navigation
+  (objectui 侧是 `DrillNavigationContext.openRecordList`)。宿主没提供时无处可跳,
+  渲染器**文档化回落**到 `'drawer'` —— 这是既定行为而非故障,点击照样打开记录,
+  只是就地打开。
+
+  注意 escape hatch 与本键无关:只要宿主接了 drill navigation,抽屉里就一直有
+  "Open in list" 动作,所以 `'drawer'` 的图表也能按需到达列表页。`'navigate'` 的
+  意义是把这次跳转变成**默认**的点击行为。
+
+  ## 影响面
+
+  `packages/lint` 的 `validate-react-page-props` 直接 parse `ChartDrillDownSchema`,
+  所以发布闸门随联合一起放行 —— 该 gate 本身一行未改。收窄未发生:三个 arm 以外的
+  `target` 仍然按值被拒。
+
+- c001422: feat(spec): declare `routes.mcp` on `ApiRoutesSchema`, and extend the discovery conformance gate one level down (#5679)
+
+  `/discovery` advertises `routes.mcp`, `objectui` reads it, and
+  `ApiRoutesSchema` never declared it. This is #4828's defect one level down —
+  with the opposite disposition: `endpoints` was retired because a census found
+  no reader, while `mcp` has two real ones (`ConnectAgentWidget.tsx` and
+  `AgentConnectSection.tsx` both gate the Integrations connect card on it), and
+  it is in fact the only `routes.*` key anything in `objectui` reads. So it is
+  declared, not removed.
+
+  Why it was a defect and not tidiness: `ApiRoutesSchema` is a plain `z.object`,
+  which **strips** unknown keys. Any consumer parsing `/discovery` through the
+  spec dropped `routes.mcp` silently — the connect card would blank with no
+  error. Nothing broke yet only because those two readers happen to read raw
+  JSON.
+
+  - **`ApiRoutesSchema` declares `mcp: z.string().optional()`**, as measured off
+    both producers rather than guessed: a path string (`/api/v1/mcp`), always the
+    **unscoped** base — `/mcp` is mounted bare, so a scoped mount advertising
+    `/api/v1/environments/env_alpha/data` still advertises `/api/v1/mcp` — and
+    `optional`, not `nullable`: the key is absent (rest-server `delete`s it, the
+    dispatcher leaves it `undefined`) when MCP is disabled or unserveable.
+    Neither producer ever emits `null`.
+  - **`@objectstack/rest` drops the two `as any` casts** at the emit site. That is
+    type-only — the emitted body is byte-identical — but the cast's disappearance
+    is the structural proof: with the key undeclared, removing it produced two
+    `TS2339 Property 'mcp' does not exist`; with it declared, `tsc --noEmit`
+    returns to its ratcheted baseline.
+  - **The #4828 conformance gates now cover `routes` keys**, not just top-level
+    ones, in all three producer packages, deriving the allowance from
+    `ApiRoutesSchema` the same way the top-level check derives it from the
+    protocol schema. Extended one level, not recursed — full recursion stays out
+    of scope, and `capabilities` / `services` are `z.record`s whose keys are open
+    by design.
+
+  - **`@objectstack/client`'s conventional route table gains an `mcp` row.** That
+    table is `Record<keyof ApiRoutes, string>` — total by design — so a newly
+    declared route owes a convention, and the public `ApiRouteType` (`keyof
+ApiRoutes`) widens by one member. The path is `/api/v1/mcp`, which is what
+    both producers emit, so the fallback agrees with the discovered value instead
+    of competing with it. Resolution behaviour is unchanged: `getRoute()` still
+    prefers the discovered route, and the pre-existing catch-all already produced
+    the same string.
+
+  Corrects one detail of the issue's premise: the runtime dispatcher's
+  `getDiscoveryInfo()` **does** also emit `routes.mcp` (its routes literal always
+  carries the key, holding the path or `undefined`), so both producers were
+  affected, not just REST — and the new gate went red on both before the fix.
+
+- 77022a9: feat(spec,runtime,metadata-protocol)!: one schema for both discovery producers — `capabilities` canonical, `features`/`endpoints` retired, `scoping` declared (#4828)
+
+  `/discovery` is a machine-readable surface, but nothing compared what the two
+  producers emit against what `packages/spec` declares. The only schema the
+  protocol layer referenced was `GetDiscoveryResponseSchema` —
+  `DiscoverySchema.partial().required({version}).extend({apiName})` — so
+  `.partial()` hid every missing REQUIRED key while zod's default unknown-key
+  strip hid every UNDECLARED emitted one. The two producers then drifted in
+  opposite directions through the same blind spot.
+
+  `DiscoverySchema` is now authoritative for producers, and each producer package
+  carries a `discovery-schema-conformance.test.ts` that parses its LIVE shape
+  against it and checks its emitted key set against the protocol schema's shape.
+
+  **Breaking for anyone reading the dispatcher's `/.well-known/objectstack` body:**
+
+  - `features` → **`capabilities`**, the name `DiscoverySchema` has always
+    declared, in the declared `{ enabled }` shape. The same flags survive. This
+    fixes a real defect: the SDK's `client.capabilities` getter reads
+    `discoveryInfo.capabilities`, so against a dispatcher-served host it returned
+    `undefined` for every flag while the answers sat one key away under `features`.
+  - `endpoints` — **removed**. It duplicated `routes` verbatim as a
+    "backward compatibility" alias; a consumer census across `objectstack`,
+    `objectui` and `cloud` found no reader. Use `routes`.
+  - `environment` is now **mapped** into its declared enum instead of passing
+    `NODE_ENV` through raw (`test` → `development`, `staging` → `sandbox`,
+    unrecognized → `development`, never `production` on a guess). `NODE_ENV=test`
+    and `staging` previously advertised values outside the declared enum.
+
+  **Additive elsewhere:**
+
+  - `DiscoverySchema` declares `scoping` (optional) — the environment-scoping
+    posture the REST endpoint has always emitted and `packages/client` has always
+    consumed, now part of the contract instead of an undeclared extra.
+  - The REST `/discovery` body gains the required `name` / `environment` /
+    `locale`, so it can satisfy `DiscoverySchema` at all. `locale` is derived from
+    the registered i18n service, the same way the dispatcher derives it.
+  - `name` is canonical on both producers. `apiName` remains as a deprecated alias
+    carrying the identical value and is **scheduled for removal in protocol 18**.
+  - New exports: `DiscoveryEnvironmentSchema`, `DiscoveryEnvironment`,
+    `resolveDiscoveryEnvironment`.
+
+- 667fa44: spec: `EmailServiceConfigSchema` 补齐 CLI 实读的 `queueDelivery` / `appName` / `defaultTemplateContext`
+
+  `config.email` 在全仓只有一个读者 —— `packages/cli/src/commands/serve.ts` 的
+  `resolveEmailCapabilityArg`。本次改动时它读八个键,`EmailServiceConfigSchema` 只声明
+  其中五个,差集三个已经被运行时消费多时:
+
+  - `queueDelivery` —— #5160 落地的耐久队列投递开关(env 侧 `OS_EMAIL_QUEUE_ENABLED`)
+  - `appName` —— 模板 `{{appName}}` 的产品名,兼作无 `defaultFrom` 时的兜底发件人来源
+  - `defaultTemplateContext` —— 合并进每次 `sendTemplate()` 的自由渲染上下文
+
+  于是用 `EmailServiceConfig` 标注 `objectstack.config.ts` 的作者写 `queueDelivery: true`
+  会拿到类型错误,而同一份配置 `os serve` 起得来、也确实走队列投递;生成的参考文档
+  `content/docs/references/system/email-config.mdx` 的属性表同样看不到这三个键,AI 作者
+  读到的是「不支持」。与 #5104(provider 缺 `smtp`)完全同型,只是键不同。
+
+  本次是把契约追平既成事实,**运行时零改动**:三个键都是 optional,不带 `.default()`
+  (默认值由 `resolveEmailCapabilityArg` 对着 env 与顶层 config 解析,schema 再造一个只会
+  多出一个谁也不赢的答案),`defaultTemplateContext` 保持自由 record —— 除 `appName` 外
+  读侧原样透传,声明一套读侧没有的约束等于发明契约。
+
+  `appName` 与 `defaultTemplateContext` 的 TSDoc / `.describe()` 按 #5448 已裁定的新序落笔
+  (`OS_APP_NAME` > `config.email.appName` > `defaultTemplateContext.appName` > 顶层
+  `appName` > `'ObjectStack'`,PR #5498 落地),因此生成的 `email-config.mdx` 属性表文案
+  随之更新:此前 context 里的 `appName` 压过 env 的旧行为已不复存在,文档不再那样承诺。
+
+  同时新增跨包契约测试 `serve-email-config-parity.contract.test.ts`,把 issue 里那条手工
+  grep 机械化:读侧多出一个未声明的键即变红,不必再等下一次人工比对。
+
+  Fixes #5307
+
+- 37e38d1: feat(spec): `EmailProviderSchema` 补上 `smtp`,并把 SMTP 的 TSDoc 与实际能力对齐 (#5104)
+
+  `EmailProviderSchema` 停在 `log` / `resend` / `postmark`,而它自己的 TSDoc 还在
+  告诉作者「Self-hosted SMTP is intentionally NOT shipped in plugin-email; apps
+  that need SMTP register a custom `IEmailTransport` themselves」。#5087 之后这两
+  句都不成立:`@objectstack/plugin-email` 已内置 `SmtpTransport`(ADR-0012,
+  `nodemailer` 惰性 import),CLI 接受 `OS_EMAIL_PROVIDER=smtp` 并读取
+  `OS_EMAIL_SMTP_HOST` / `_PORT` / `_SECURE` / `_USER` / `_PASSWORD`。
+
+  结果是 declared ≠ implemented,而且是 **spec 落后于运行时** 的那一侧:用
+  `EmailServiceConfig` 标注 `objectstack.config.ts` 的作者,写
+  `provider: 'smtp'` 会拿到类型错误 —— 而这个 provider 早就能正常投递;生成的参考
+  文档 `system/email-config` 也只列三个值,读到的 AI 作者会认为 SMTP 不受支持。
+
+  **改动(纯加值,非破坏性):**
+
+  - `EmailProviderSchema` 增加 `'smtp'`。已有配置不受影响,无需 ADR-0087
+    conversion / migration。
+  - 重写该段 TSDoc:SMTP 由 plugin-email 内置,`nodemailer` 惰性加载;并写明
+    `sendgrid` / `ses` **不是**成员 —— 两者从未实现 HTTP-API transport,都通过
+    `provider: 'smtp'` 连各自的 SMTP 端点(#5094)。
+  - `provider` 与 `options` 补 `.describe()`,所以参考文档现在正面说明:
+    `provider: 'smtp'` 的连接参数放在 `options` 的 `host`(必填)/ `port` /
+    `secure` / `user` / `password`,与 `OS_EMAIL_SMTP_*` 一一对应,env 优先。
+
+  **运行时零改动。** 这一单只把契约追平既成事实;plugin-email 与 CLI 未被修改。
+
+  新增的跨包契约测试把这份 provider 词表与 `@objectstack/plugin-email` 的
+  `EMAIL_TRANSPORT_PROVIDERS`(`makeTransport` 实际 switch 的数组)双向锁死,
+  两侧任一方单独增删都会红 —— 下一个 provider 必须两边都有意识地改。
+
+- c52e608: fix(metadata,spec): the endpoint publish gates now guard the metadata write path too (#5189, #5040 E7b)
+
+  #5111 (E7) hung the five per-endpoint `apis:` gates on
+  `ObjectStackDefinitionSchema`, which every path that parses a **stack** runs
+  through — `defineStack`, `os validate`, the lint scorer, artifact ingest,
+  `EnvironmentArtifactSchema.metadata`. #5189 proved a stored `api` item need
+  never have been part of a stack: `MetadataManager.publishPackage`, a direct
+  `metadata.register()` and a Studio metadata write each mint one item at a time
+  and saw no gate at all.
+
+  Three of the five gates degrade safely when bypassed — the executor answers a
+  structured 501 naming the item, and a path outside the `apps/<namespace>/`
+  carve-out simply matches nothing. **ADR-0121 D6 has no runtime counterpart**:
+  the runtime honours `authRequired: false` faithfully and `deriveBucketConfig`
+  returns `null` for a budget whose `enabled` is not `true`, so the bypass minted
+  an anonymous, zero-quota execution entry point — the exact shape D6 exists to
+  forbid.
+
+  Two doors now, both running the SAME gate function rather than a second copy of
+  the criteria:
+
+  - **Publish** — `MetadataManager.publishPackage` runs
+    `validateApiEndpointDeclarations` over the package's `api` items and fails
+    the publish, naming each endpoint and the key to fix, on the same
+    `validationErrors` surface it already uses. This pass is **not** governed by
+    `options.validate`: an opt-out on a security gate is the bypass this fixed.
+  - **Load** — the endpoint matcher's index build re-applies the _identity-free_
+    subset (supported subset, mapping, policy/D6) to every stored item. A
+    declaration that never passed publish is EXCLUDED from the index and named at
+    `error` level, so a bypassed endpoint answers 404 with a loud log instead of
+    answering anonymously and unmetered. The namespace and uniqueness gates are
+    deliberately not applied there — both need a stack identity a stored row does
+    not carry.
+
+  **New in `@objectstack/spec/api`** (the module was package-internal in #5111,
+  whose only consumer was one file away):
+  `validateApiEndpointDeclarations`, `identityFreeEndpointGateFailure`,
+  `EndpointGateIssue`, `EndpointGateIdentity`.
+
+  **New option — `publishPackage(id, { namespace })`.** `MetadataManager` indexes
+  items by `packageId` and carries no manifest, so it cannot prove a namespace on
+  its own and will **not** infer one from the items it is judging (an
+  author-supplied value would make the ADR-0121 D1/D2 carve-out gate vacuous).
+  Callers that hold the package manifest pass its explicit `manifest.namespace`;
+  without it the namespace gate fails and the package's `api` items do not
+  publish — which is the rule, not a limitation: a publish that cannot prove a
+  namespace must not mint a URL under one. Packages that declare no `api` items
+  are untouched.
+
+- 77be690: feat(spec): 执行器契约面 —— `IMetadataService.matchEndpoint?` 与 `IHttpServer.setFallbackHandler?` 可选成员(#5040 执行器 E1)
+
+  **纯声明,零行为变更。** 本改动只在 `packages/spec/src/contracts/` 增加两个**可选**契约成员与一个导出类型;仓内没有任何实现体、没有任何接线,现网行为逐字节不变。声明式 `ApiEndpoint` 在 v17 仍被 publish 硬拒(#4936 裁决),本单落的是它未来得以执行所需的契约前件(contract-first 首件)。
+
+  **1. `IMetadataService.matchEndpoint?(query: { path, method })`** — 把一次请求的 `method`+`path` 解析为拥有该路由的 `api` 元数据条目,或在无人声明时返回 `undefined`。这是 HTTP dispatcher 在「内建 domain 均未认领」与「答语义 404」之间的那一步。随之导出新类型 `ApiEndpointMatch`:
+
+  - `endpoint` 是 `ApiEndpointSchema.parse` **之后**的形状 —— 默认值已物化,而非存储里的原始 JSON。作者漏写 `authRequired` 时消费端拿到的是 `true`(schema 默认值),因此消费端永远读不到「缺省」这个中间态,也就不可能把一个缺失的安全默认误读成放行。
+  - `params` 在 17.x **恒为 `{}`**。`ApiEndpointSchema.path` 词表已冻结(ADR-0121),既未定义 `:param` 也未定义 `{param}`,本契约**刻意不发明**模板语法 —— 只存在于实现里的语法就是隐藏方言(Prime Directive #12)。槽位现在就声明出来,是为了将来真要加路径模板时,那是词表的加法,而不是本契约的破坏性变更。
+
+  **2. `IHttpServer.setFallbackHandler?(handler: RouteHandler)`** — 传输层兜底 seam:仅当**全部显式注册的路由均未命中**后才被调用。它在结构上不可能遮蔽任何已注册路由,因此零注册顺序依赖 —— 这正是它优于「通配路由」方案的原因,后者由插件 `start()` 顺序下的 first-registration-wins 决定归属,即 ADR-0076 D11「一条路由一个属主」要防的病灶。第二条保证同样载入契约:兜底 handler 收到的 `req.body` **可读**,与 `use()` 中间件契约明确「body 不填充」相反(在 `use()` 处解析 body 会在真正拥有它的路由 handler 之前吃掉请求流)—— 这条差异正是中间件 seam 无法承载动态端点、而必须新增本成员的原因:由 flow 或 `create` 操作支撑的声明式端点必须读 body。
+
+  **两者均为可选成员**,消费端按仓内既有惯例以 `typeof x === 'function'` 探测(同 `watch?` / `subscribe?` / `getRawApp?`)。不实现它的 `metadata` 槽位占用者、无法表达 not-found 钩子的适配器,都仍然满足契约,消费端退化到既有的未命中应答。因此对现有实现方**无迁移动作**。
+
+  生成物影响:`api-surface.json` 新增一行 `ApiEndpointMatch (interface)`(0 breaking / 1 added)。两个新成员是 interface 成员而非导出,不动其余七件生成物。
+
+- b49ccfd: feat(spec): declare `FilterArray` as the input-only authoring sugar it already was (#5285)
+
+  `FilterArray` had a name and no definition. Three READMEs, `llms.txt`, four
+  skills, the query-adapter docs and this package's own react-blocks prop table
+  all taught authors to write it — `filters={['status', '=', stage]}` — while the
+  protocol never declared it anywhere. An author following the contract they were
+  handed had nothing to validate against, which is worst for the AI authors these
+  contracts are largely written for: the name looked resolvable and was not.
+
+  `packages/spec/src/data/filter.zod.ts` now declares it, next to the operator
+  vocabulary it is built from and the sink it lowers through:
+
+  - **`FilterArray`** (type) plus `FilterArrayComparison`, `FilterArrayGroup`,
+    `FilterArrayList` — the three shapes the measured producers emit: a comparison
+    `[field, operator, value]` (with the real two-element form for the null
+    predicates, whose direction lives in the operator name), a group
+    `['and' | 'or', ...conditions]`, and a bare list combined with implicit AND.
+  - **`FilterArraySchema`** — the Zod authoring gate.
+  - **`FilterArrayOperator`** — the canonical operator spellings, derived from
+    `AST_OPERATOR_MAP` rather than restated, so it cannot drift from the lowering
+    the way two hand-written lists did in #3948. A misspelled operator is now a
+    type error where the shape is authored in TypeScript, instead of an unknown
+    `$`-operator arriving at a driver.
+  - **`FILTER_ARRAY_LOGIC_KEYWORDS`** / `FilterArrayLogicKeyword` — `'and' | 'or'`.
+
+  **Input-only, and that is the whole point.** This is sugar accepted at
+  authoring entrances (React block props, the client `FilterBuilder`, the wire
+  `$filter` face). It is lowered to a `FilterCondition` at the single sink
+  `parseFilterAST` the moment it arrives, and only the lowered form travels any
+  further. **Nothing about the storage or wire contract changes**: a query's
+  `where` is a `FilterCondition` and stays one, deliberately excluding the array
+  dialect so no driver, transport or stored row ever has to understand two filter
+  languages. `filter-array-declaration.test.ts` pins that exclusion as a negative
+  test, so a future widening of the protocol face fails loudly and lands the
+  reader on the ruling that decided it.
+
+  Nothing to migrate: every filter that worked before works unchanged, and the
+  declaration adds the check that was missing. Per #5158's ruling C, this is step
+  one of two — the engine-side lowering that closes the second door is separate.
+
+- 85d95e7: feat(spec): `$icontains` 入算子词表(ASCII 折叠域)、`$contains` 族钉死为大小写敏感、`$regex` 退役指引表(#5701)
+
+  #4706 维护者裁决 B 案的**契约半边**。本次只改声明,不改任何运行时行为:
+  五个后端今天怎么答,落地后还怎么答。驱动侧下译归 #5702,`$regex` 唯一活生产者的
+  翻转归 #5710。
+
+  ## 1. 新增 `$icontains` —— 折叠域是 ASCII,不是 Unicode
+
+  `StringOperatorSchema` / `FieldOperatorsSchema` / `Filter<T>` 新增 `$icontains`:
+  忽略大小写的子串包含,**只折叠 `A-Z` 与 `a-z`**。
+
+  ```ts
+  {
+    name: {
+      $contains: "acme";
+    }
+  } // 大小写敏感:匹配 "acme corp",不匹配 "ACME Corp"
+  {
+    name: {
+      $icontains: "acme";
+    }
+  } // 折叠 ASCII 大小写:两者都匹配
+  ```
+
+  **边界必须说清楚:`café` 不匹配 `CAFÉ`。** ASCII 以外一律按字面比较。
+  选 ASCII 而非全 Unicode,是因为它是五个后端唯一都能真兑现的折叠域 ——
+  无 ICU 的 SQLite(`driver-sqlite-wasm` / `driver-turso` 跑的就是它)的
+  `LOWER()` 与 `LIKE` 只折叠 ASCII,承诺 Unicode 等于承诺三个后端做不到的事,
+  那正是 #4706 用来否决「五后端真正则」的同一条判据。
+
+  比较值一律**字面量**:`%` / `_` 不是 LIKE 通配符,`.` / `*` 不是正则元字符 ——
+  `{ name: { $icontains: 'a.b' } }` 匹配 `a.b`,不匹配 `axb`。
+
+  ## 2. `$contains` / `$notContains` / `$startsWith` / `$endsWith` = 大小写敏感
+
+  这条**取代**了 `filter.zod.ts` 里那句已记录的声明(Prime Directive #13,
+  取代记录写在原处):
+
+  > Note: Case sensitivity should be handled at backend level.
+
+  那不是漏写,是写下来的「不保证」,实测代价是同一个算子三种答案:
+  `driver-memory` 的参考匹配器与 `formula` 大小写敏感,`driver-mongodb` 硬编码
+  `$options: 'i'` 全 Unicode 不敏感,SQL 家族看方言(SQLite 折叠 ASCII、
+  Postgres 不折叠、MySQL 看 collation)。作者无法从算子名判断自己拿到哪一种。
+
+  **迁移**:此前依赖某后端偶然大小写不敏感的 `$contains` 查询,应改写为
+  `$icontains`。行为在 #5702 落地前不变,所以这是一次可以提前做的改写,不是断裂。
+
+  ## 3. `$regex` / `$options` 退役 —— 指引表 `RETIRED_FILTER_OPERATORS`
+
+  `$regex` 从来不在 `FILTER_OPERATORS` 里,却有一个生产者、四个消费者,而且各读各的:
+  `driver-sql` 编译成 LIKE 转义后的子串匹配(`a.b` 只匹配字面 `a.b`),
+  `driver-memory` 当真正则求值(`a.b` 还匹配 `axb`;模式非法则被 `catch` 成零行,
+  无声)。真正则在五后端不可实现 —— `driver-turso` 的 remote 线协议无法注册
+  SQLite `REGEXP` 函数。
+
+  新增 `RETIRED_FILTER_OPERATORS`(**纯数据**,不引入任何拒收行为),
+  给出逐条处方,供五个既有拒收点引用同一句话:
+
+  | 原写法                                        | 改写为                              |
+  | :-------------------------------------------- | :---------------------------------- |
+  | `{ name: { $regex: 'acme' } }`                | `{ name: { $icontains: 'acme' } }`  |
+  | `{ name: { $regex: 'acme', $options: 'i' } }` | `{ name: { $icontains: 'acme' } }`  |
+  | `{ name: { $regex: '^acme' } }`               | `{ name: { $startsWith: 'acme' } }` |
+  | `{ name: { $regex: 'acme$' } }`               | `{ name: { $endsWith: 'acme' } }`   |
+
+  真正需要正则的查询没有 filter 层替代物:用已声明算子收窄,再在应用代码里匹配。
+
+  ## 4. 新姊妹 case-set `FILTER_TEXT_CASES`
+
+  `filter-text-conformance.ts` —— 大小写折叠、字面比较值、`$regex` 拒收的共享标准,
+  带 `expectRejection` 判别式(`FILTER_LOGIC_CASES` 刻意没长出来的那个形状,
+  其表头三条章程原样保留)。五个 driver 各记一条**实测** DEBT 台账,指向 #5702。
+
+  ## 什么**没有**变
+
+  `$icontains` 暂不进 `FILTER_OPERATORS`。那个数组不是词表而是运行时白名单 ——
+  `driver-memory` 的 `SUPPORTED_FIELD_OPERATORS` 由它派生。实测:提前把
+  `$icontains` 放进去,该驱动的形状门禁就不再拒收它,而匹配器没有对应分支,
+  `match({name:'zzz'}, {name:{$icontains:'acme'}})` 返回 `true` —— 谓词被静默丢弃,
+  全表命中。谓词被丢不是收窄而是**放大**,在 RLS 读作用域上是越权读(#3948)。
+  所以它随 #5702 的实现一起入列,`filter-operator-vocabulary.test.ts` 把这处差异
+  钉死为恰好 `{ $icontains }`,清偿时该断言会红,提醒作者一并删掉过渡说明。
+
+- 168f60f: feat(spec,automation): `update_record` / `delete_record` can declare bulk intent with `multi` (#5393)
+
+  A flow could not express "write every row this filter matches" — at all, from
+  any app. `UpdateRecordConfigSchema` / `DeleteRecordConfigSchema` are
+  `strictObject`s and neither declared any spelling of bulk intent (`multi`,
+  `bulk`, `all` and `options.multi` were each rejected as an unrecognized key),
+  and the CRUD executors never passed `options.multi` to the data engine. The
+  engine accepts a write only when `where.id` is a **scalar** or `options.multi`
+  is truthy, and throws otherwise — so a predicate `update_record` /
+  `delete_record` was unreachable, while the node descriptors advertised
+  `Delete Records` / "Delete records matching a filter." Declared ≠ enforced
+  (Prime Directive #10); the symptom was #5225's showcase sweep flow, which had
+  never deleted a record.
+
+  **New authorable key — `multi` (boolean, default `false`), on `update_record`
+  and `delete_record`.** One name for one concept (PD #12): `multi` is what the
+  data engine has always called it (`EngineUpdateOptions.multi` /
+  `EngineDeleteOptions.multi`), so the word is the same from node config to
+  driver call and greps end to end.
+
+  ```ts
+  // before — refused by the engine at run time, with no authoring-time signal
+  { type: 'delete_record', config: { objectName: 'lead', filter: { stage: 'stale' } } }
+
+  // after — the declaration makes the intent explicit and the write reachable
+  { type: 'delete_record', config: { objectName: 'lead', filter: { stage: 'stale' }, multi: true } }
+  ```
+
+  - **Absent or `false`** — unchanged behaviour. The executor forwards
+    `multi: false`, so the write must name one row by scalar `id`; anything else
+    (a predicate, or `id: { $in: [...] }`) is refused by the engine with
+    `Delete requires an ID or options.multi=true`. **That refusal is the
+    contract**, not a defect to route around: it is what keeps an undeclared
+    unbounded write from happening by accident.
+  - **`true`** — the executor forwards `options.multi: true`, the write lands on
+    `driver.updateMany` / `deleteMany`, and the step's `acted` metric reports the
+    affected row count.
+
+  Additive and backward compatible: no existing flow changes behaviour, and every
+  by-id write keeps working untouched.
+
+  Two guards are unchanged and worth stating explicitly. The #3810
+  erased-condition guard still refuses a node whose authored filter condition
+  interpolated to nothing, `multi` or not — bulk intent says "many rows are
+  fine", never "a condition may vanish". And `multi: true` with **no** `filter`
+  is the whole object, by declaration: write the constraint you mean.
+
+  Wrong spellings are answered by name rather than by edit distance (which
+  reaches `multi` from none of them): `bulk` / `all` / `multiple` get the
+  prescription, and `options: { multi: true }` is called out as the engine's
+  options bag written at the node's altitude.
+
+- 546ab3c: `formatZodError` no longer cuts a union branch's rejection down to `Invalid input` (#4971).
+
+  Zod raises exactly one issue for a failed `z.union` — `invalid_union`, whose own
+  `message` is the literal string `"Invalid input"` — and keeps each branch's real
+  issues one level down in `issue.errors[]`. `formatZodError` mapped `error.issues`
+  and never descended, so every rejection behind a union reached the author as:
+
+  ```
+  Action ref (1 issue):
+
+    ✗ (root): Invalid input
+  ```
+
+  while the same class of mistake on a plain `strictObject` rendered its full
+  prescription. The prose was never lost — the REST error body and
+  `ZodError.message` carry the payload through. What dropped it is every consumer
+  that flattens to one line, and `formatZodError` is one: it is this package's
+  documented CLI formatter and what `defineStack` throws through, so an author
+  whose stack config has a union mistake reads it on every command that loads the
+  stack. Every `strictObject` that sits inside a union was affected; `ActionRef` /
+  `GuardRef` in `automation/state-machine.zod.ts` are the measured specimens, and
+  the surface grows with each #4001 strictness batch.
+
+  The formatter now expands a failed union one level deeper:
+
+  ```
+  Action ref (1 issue):
+
+    ✗ (root): Invalid input
+      ✗ (root): Unrecognized key(s) on this action reference: `args`. Until #4001 …
+  ```
+
+  **What gets printed, and what deliberately does not.** Printing every branch is
+  the failure this fix must not cause — a plain union of four strict members
+  reports one bad key once per member, which is why `view.zod.ts`'s
+  `submitBehavior` moved to `discriminatedUnion`. So branches are selected, not
+  dumped:
+
+  - A branch that only says the value is the wrong **kind** at its root
+    (`expected string, received object`, from the `z.string()` member of
+    `z.union([z.string(), SomeObject])`) carries no prescription and is dropped.
+    When _every_ branch is one — `z.union([z.string(), z.number()])` handed an
+    object — nothing is expanded and the output is byte-identical to before.
+  - Among the rest, the branch reporting the **fewest** issues wins: the member
+    the author was aiming at complains only about the stray key, while the others
+    also report a wrong discriminator and their own missing requireds. A
+    `unrecognized_keys` issue breaks a tie, declaration order breaks what remains.
+  - Branches that genuinely tie are all rendered (max 3), and identical verdicts
+    across them are printed once — so a single unknown key is reported once, never
+    once per branch.
+  - Nested unions expand recursively with absolute paths
+    (`✗ states.s.on.GO.actions.0: …`), bounded to three levels.
+
+  The issue **count** in the header is unchanged: it stays `error.issues.length`,
+  so the CLI keeps agreeing with the structural consumers about how many things
+  are wrong — a union is one issue however many lines explain it.
+
+  User-visible for anyone who prints `formatZodError` / `formatZodIssue` /
+  `safeParsePretty` output, including `defineStack`'s thrown message. No schema,
+  signature or accepted input changes.
+
+- ef4efa8: feat(spec): `HookContext.session` declares `positions` and `preserveAudit` (#5605)
+
+  Two keys the engine has been **producing** all along, that consumers have been
+  **reading** and the docs have been **teaching**, were missing from the contract:
+  `HookContextSchema.session` declared `userId` / `actor` / `organizationId` /
+  `accessToken` / `isSystem` / `skipTriggers` / `skipAutomations` and nothing else.
+  Both are now declared, per the maintainer ruling on #5605.
+
+  This is the mirror of the `session.roles` retirement (#5050). That key was
+  declared-never-produced, so it was removed; these two are
+  produced-never-declared, so they are added. Same `session` block, opposite
+  drift, opposite fix.
+
+  **What was broken.** `HookContextSchema` is deliberately not `.strict()` — it is
+  the runtime shape the engine hands a handler, and strictness there would make
+  every engine-side enrichment a breaking change for anyone parsing a context they
+  were given. The cost of that tolerance is that an undeclared key is **stripped
+  in silence**:
+
+  - `HookContextSchema.parse(ctx)` — the exact call the generated reference page
+    documents as the way to consume a context — returned a session with the
+    caller's `positions` and the import's `preserveAudit` dropped on the floor.
+  - A handler typed the way the automation docs teach, `(ctx: HookContext)`, could
+    not read either key: `ctx.session?.positions` was a `TS2339`. The two
+    `kernel/runtime-services` pages that teach
+    `positions: ctx.session?.positions` compiled only because they annotate `ctx`
+    as `any` — copying both the code and the documented annotation did not build.
+
+  **`positions`** (`string[]`, optional) is the ADR-0090 D3 placement vocabulary,
+  copied verbatim from `ExecutionContext.positions` by ObjectQL's `buildSession()`.
+  Its `.describe()` states the boundary the ruling asked for, because the boundary
+  is the whole reason this key needed a decision rather than a patch: it is
+  **readable context, never an authorization input**. A hook may forward it as the
+  sharing service's evaluation context, tailor a message, or log it. A hook must
+  not make the access decision itself by testing it — privilege is judged by the
+  security service on the execution context (capability grants `permissions`,
+  placements `positions`, and the derived posture). A hook re-deciding access from
+  this array decides, somewhere with no access to the grant model, something that
+  was already decided; that is structurally the mistake the `roles` tombstone
+  exists to prevent, one vocabulary later.
+
+  **`preserveAudit`** (`boolean`, optional) is the #3493 historical-import flag:
+  server-set, opt-in, absent on normal writes, and read by the built-in audit hook
+  to keep a caller-supplied `updated_at`/`updated_by` instead of stamping the
+  import instant. It has a live consumer, so it could only ever be declared.
+
+  Purely additive — both keys are optional, the shape stays non-strict, and no
+  existing context, handler or stored metadata changes. Contexts are built per
+  operation and never persisted, so there is nothing to migrate.
+
+- 55dbbba: feat(spec,runtime,hono): `server.security.rateLimit` — an authored budget that actually returns 429 (#4910, #4937)
+
+  Rate limiting in ObjectStack was three shapes with nothing between them. `packages/spec`
+  declared `RateLimitConfig` in three places and the whole repo had **zero readers** for any
+  of them, so an author wrote a budget, it parsed, and nothing happened (#4686).
+  `@objectstack/runtime` shipped a token bucket whose comments claimed, in the present tense,
+  that the dispatcher called it and short-circuited with 429 — it had **zero call sites**
+  outside its own unit test, and the `DispatcherPluginConfig.rateLimit` field it told you to
+  tune did not exist (#4937). Neither half was broken; they were simply never connected, and
+  both were documented as if they were.
+
+  They are connected now, along one narrow path.
+
+  ## What you write
+
+  ```ts
+  export default defineStack({
+    manifest: {
+      /* … */
+    },
+    server: {
+      security: {
+        rateLimit: { enabled: true, windowMs: 60_000, maxRequests: 600 },
+      },
+      trustProxy: false,
+    },
+  });
+  ```
+
+  `server:` is a **new** top-level stack key. Nothing declared it before, so no existing
+  stack changes behaviour on upgrade — there is no configuration that was inert yesterday
+  and starts throttling today.
+
+  It is deliberately **narrow**: it carries `security.rateLimit` and `trustProxy` and
+  nothing else, because those are the two keys with a consumer. It is NOT the nine-key
+  `HttpServerConfigSchema` — the other seven have no reader and no authoring surface, and
+  mounting them here would have made seven dead keys writable in one move (their
+  enforce-or-remove fate stays with #4938). It is strict from birth (#4001), so a misspelled
+  budget is rejected with the correction rather than silently defaulted, and `maxRequests: 0`
+  is refused at `defineStack` rather than at 3am.
+
+  **No `server.port`.** The listening socket belongs to the deployment, not the artifact, and
+  `objectstack serve -p` already owns it. The precedence rule is recorded in the schema and
+  the docs in advance, so it cannot be re-litigated per caller: **CLI flag > `server:` >
+  built-in default.**
+
+  ## What happens
+
+  Every inbound request the server routes — REST, dispatcher, service routes, anything
+  mounted on that transport — consumes from a token bucket sized `capacity = maxRequests`,
+  refilling at `maxRequests / (windowMs / 1000)` per second. An empty bucket answers **429**
+  with a `Retry-After` computed from the bucket itself and the standard error envelope
+  (`code: "RATE_LIMIT_EXCEEDED"`). `OPTIONS` preflights are never metered.
+
+  The bucket is keyed by **resolved principal**, falling back to the caller's **IP** for
+  anonymous traffic — so one abusive session cannot spend another user's budget, and
+  credential-stuffing traffic (which has no principal yet) is still metered per source. That
+  IP comes from `X-Forwarded-For` / `X-Real-IP` **only when `trustProxy: true` is declared**;
+  otherwise it is the transport's own peer address. Undeclared, those headers are attacker
+  input: honouring them by default would hand anyone an unlimited supply of fresh buckets and
+  let them drain a chosen victim's.
+
+  Counters live in the kernel `cache` service when one is registered, so a multi-node
+  deployment enforces one budget instead of one per node (ADR-0069 D2), resolved lazily at
+  consume time so a cache plugin that registers later is still picked up (#4772). With no
+  cache service at all it falls back to a per-process store and says so once, naming the
+  consequence: the effective limit becomes the declared budget multiplied by the number of
+  nodes, and nothing about the deployment looks wrong.
+
+  ## Also in this change
+
+  - **`IHttpServer.use()` is a real middleware seam.** The Hono adapter's implementation
+    passed `{}` for both `req` and `res` and called `next()` unconditionally, so a registered
+    middleware could not read the request, write a response, or decline to continue — a
+    declared seam with no execution behind it, unnoticed because nothing called it. It now
+    delivers method/path/query/headers plus the transport peer address
+    (`IHttpRequest.remoteAddress`, new), and honours a short-circuit. Middleware must be
+    registered before the routes it guards; the kernel's two-phase boot makes that automatic
+    (`init()` before every `start()`).
+  - **`packages/runtime/src/security/rate-limit.ts` no longer describes an execution chain it
+    does not have** (#4937). The token-bucket arithmetic is extracted so the synchronous
+    in-process limiter and the new shared-store one cannot drift, and `DEFAULT_RATE_LIMITS` is
+    now labelled as the reference material it always was rather than as live defaults.
+
+  ## Explicitly NOT wired
+
+  `ApiEndpointSchema.rateLimit` and `ApiEndpointRegistrationSchema.rateLimit` remain
+  **known-unwired**. Declaring them still changes nothing. They are not retired here either:
+  the fate of the whole declarative `apis:` surface is undecided (#4936), and retiring one
+  key of a surface that may yet be implemented would only have to be undone. Tracked, not
+  silent.
+
+- 7f1a635: fix(lint,spec,objectql): 编写期表达式与 `highlightFields` 校验识别注册表注入的系统列 (#5378)
+
+  平台在每个业务对象上注入 `owner_id` / `created_at` / `organization_id` 等系统列,
+  文档也把 `ownership: 'user'` 写作 "injects reassignable owner_id"。但编写期的两处
+  校验只读**作者声明的** `fields`,于是注入列一律当作不存在:
+
+  - `validate-expressions.ts` 的 `buildFieldIndex` 让 `has(record.owner_id)` 直接
+    报错 `unknown field owner_id`;
+  - `highlightFields` 存在性检查对 `['owner_id']` 发出 "is not a field on this
+    object — it is silently skipped by every consumer"。
+
+  也就是平台自己的 linter 否认平台自己的契约。结果是应用被迫**重声明系统列**才能通过
+  编写期校验:hotcrm#548 为此在全部 12 个业务对象上显式声明了 `owner_id`(6 个对象曾
+  报 `highlightFields` 警告,`contact_welcome` 触发器的 `has(record.owner_id)` 被硬
+  拒)。这正是本项目视为缺陷的形状:能力已声明(列确实注入且有文档),但执行层不认。
+
+  **权威来源只有一份。** 新增纯派生 `resolveInjectedSystemColumns()`
+  (`@objectstack/spec/data`)回答"这个对象带哪些系统列",并由 registry 的
+  `applySystemFields()` **消费**它——沿用 #3786 为审计字段族确立的分工:spec 声明
+  **有哪些**列,registry 拥有**每列长什么样**。lint 通过同一派生取答案,因此编写期
+  判断与运行时注入不可能不一致(`@objectstack/lint` 的包契约是"只依赖 spec,绝不依赖
+  运行时",此前它根本无法读到权威)。两个消费面共用同一判定,不各写一份。
+
+  **并入是按对象有条件的**,不是无条件放行整张系统列名单:`ownership: 'org' | 'none'`
+  的对象没有 `owner_id`,那里的 `record.owner_id` 仍然是真错误并继续报;
+  `tenancy.enabled: false` 无 `organization_id`;`systemFields: { audit: false }` 无
+  审计四列;`systemFields: false` / `managedBy: 'better-auth'` 什么都不注入(只剩驱动
+  提供的主键 `id`)。真正拼错的字段照旧被拒,并且注入列现在也进入 "did you mean?" 候选
+  (`record.ownerid` → 提示 `owner_id`)。
+
+  被解析的注入列在诊断与补全语义上与授权字段等同;类型健全性与 null-guard 两个索引
+  **刻意**仍只读声明字段,原因写在各自注释里:列的 `type` 与可空性属于 registry 的列
+  定义,在 lint 侧另立一份就是本次要消灭的第二份副本,而 null-guard 喂的是会中断构建的
+  判定,擅自并入会让今天能构建的 stack 变红。
+
+  注入行为本身零改动:`applySystemFields` 的输出在全条件矩阵上逐列不变(新增 parity
+  pin 用实跑注入代码比对)。已显式重声明系统列的应用不受影响——重声明仍然合法,
+  examples 三个 app 的 `os validate` 输出改动前后完全一致。
+
+- 089767f: feat(spec): `page-header` 节点的 `description` 在加载期改写为 canonical 的 `subtitle` —— ADR-0087 D2 条目 `page-header-subtitle-alias`(#4827,objectui#3226)
+
+  「页面副标题」这一个概念长期有两套 authorable 拼写,一套渲染器一套:`@objectstack/spec`
+  的 `PageHeaderProps` 只声明 `subtitle`,而 objectui 的 kebab 遗留别名 `page-header`
+  在注册 `inputs` 里宣告 `description`,渲染器用一个裸 `subtitle ?? description` 兜住 ——
+  正是 Prime Directive #12 描述的「producer 写方言、consumer 用 `??` 兜」。
+
+  现在按 ADR-0087 D2 收口:protocol 17 的 **live window** 条目
+  `page-header-subtitle-alias`,在加载期(`defineStack` / `validate` / `lint`,以及
+  `applyConversionsToStoredItem` 覆盖的 `sys_metadata` 存量行)把 page-header 节点
+  `properties` 上的 `description` 改写为 `subtitle`,每次改写发出一条结构化
+  `ConversionNotice`。消费端因此只需读 `subtitle`;objectui#3226 随后删掉那个 `??`。
+
+  FROM → TO:
+
+  - `pages[].regions[].components[]`,`type` 为 `page-header`(kebab 遗留别名)或
+    `page:header`(协议 canonical 键):`properties.description` →
+    `properties.subtitle`
+
+  两点语义按既有惯例、并有测试钉住:
+
+  - **canonical 优先**:`subtitle` 已在场时不改写、不发通知,被遮蔽的 `description`
+    原样留在那里(与 `flow-node-crud-object-alias` 一致)。
+  - **只动 header 节点**:`description` 在同一层的其他组件上是活的已声明属性
+    (`element:text_input` 的辅助文本),不受影响。
+
+  本条目**不**改写节点 `type`:kebab 别名的存废是 objectui 侧的事,按其自身节奏推进。
+  `description` 从未在 `PageHeaderProps` 上声明过,因此没有 schema 键被移除,也无需
+  tombstone;老拼写在 protocol 17 全程被接受,18 退出加载路径并转入 D3 迁移链。
+
+- acb10f6: feat(spec): `ProvisionEnvironmentResponse` 增加可选 `hostnameAssignment` —— 自动改名的响亮回执 (#5185)
+
+  环境的 canonical hostname 是 UNIQUE 的。provision 时若请求的 hostname 撞车,控制面不会让整个
+  调用失败,而是追加一小段后缀自动改名。改名以前**只体现在返回的 `environment.hostname` 上**——
+  调用方除非自己把请求的 hostname 存下来再逐字符比对,否则无从知道自己拿到的并不是自己要的那个。
+
+  `ProvisionEnvironmentResponseSchema` 新增可选字段:
+
+  ```ts
+  hostnameAssignment: {
+    requestedHostname: string; // 调用方要的(显式传入,或由 displayName 推导)
+    assignedHostname: string; // 改名后实际分配的,等于 environment.hostname
+  }
+  ```
+
+  **语义是「仅在真的发生了自动改名时才填充」**:没撞车、原样分配的调用完全不带这个键,因此
+  `hostnameAssignment !== undefined` 本身就是信号。⛔ 不要把「缺席」读成「未知」。
+
+  为什么必须声明在 spec、而不是控制面本地 extend(cloud#1070 方案 C,维护者已批):
+
+  - 控制面本地 extend 出来的是**未声明的兄弟键**,`z.object` 出站即剥离 —— 回执靠蒸发「合规」;
+  - 塞进自由格式的 `metadata` 袋:在 caller-wins 先例下,调用方可以压制、也可以伪造这个由服务端
+    发出的信任信号;
+  - AI 生成的 provisioning 客户端按本协议已发布的表面(`api-surface.json`)生成 —— 字段不进
+    spec 表面,生成出来的客户端永远不会去读它。
+
+  纯增量的可选字段:既有的 provisioning 响应(不带该键的)照旧合法,无需改动任何调用方。
+
+- 889ae47: feat(spec)!: `RecordDetailsProps.sections` declares the object form every page actually authors, and `hideFields` is declared (#5611)
+
+  `record:details` declared a `sections` shape that nothing produced and nothing
+  consumed, and omitted a key a published platform page depends on. Both are now
+  declared as delivered.
+
+  **BREAKING (authored metadata shape) — `sections` is an object array, not an ID list.**
+
+  ```ts
+  // FROM — declared, but written by zero pages and read by zero renderers
+  sections: ["overview", "financials"];
+
+  // TO — what every real page already authors
+  sections: [
+    { label: "Overview", columns: 2, fields: ["name", "account", "owner"] },
+    { label: "Financials", columns: 2, fields: ["budget", "spent"] },
+  ];
+  ```
+
+  One-line fix: replace each section ID with `{ fields: [...] }`, naming the
+  fields that section should render (add `label` for a heading, `columns` for its
+  grid width, `name` to make the heading translatable).
+
+  **Why this is safe despite being a type change — it was measured, not assumed.**
+  The ID-list form had **zero** read paths and **zero** producers:
+
+  - `objectui`'s `RecordDetailsRenderer` maps every `sections` entry as an object
+    (`s.name` / `s.label` / `s.title` / `s.fields`) and has no string branch — a
+    string entry would spread into a character map and render nothing;
+  - `@object-ui/types`' `RecordDetailsComponentProps` mirror already declared
+    `Array<{ name?, label?, fields, ... }>`, and the Studio block designer can only
+    author `{ label, columns, fields }`;
+  - every page in this repo authors the object form — three showcase pages
+    (`project-detail`, `task-detail`, `settings`) and the `sys_user` platform page;
+  - `packages/lint` has modelled it as `nestedSections` (`sections[].fields[]`) all
+    along.
+
+  So the "breakage" applies only to hypothetical stored metadata written against a
+  declaration nothing ever honoured, and schema validation runs on the publish
+  path — it does not rewrite data at rest.
+
+  **New: `hideFields`.** `z.array(z.string()).optional()` — field names omitted
+  from the body, applied to `fields` and to every section's `fields`. The
+  `sys_user` platform page has authored it since it shipped and the renderer reads
+  it; it was undeclared, so it survived only because per-component `properties` is
+  never parsed. Declaring it now means the parse gate (#5068) preserves it instead
+  of silently stripping a live page's hidden-field list.
+
+  **Section keys**, each declared because it is delivered end to end:
+  `fields` (required), `label`, `columns` (1-4), and `name` — the i18n anchor that
+  resolves `objects.<object>._sections.<name>.label`, which `packages/lint`'s
+  `translation-section-name-missing` rule tells authors to add.
+
+- 4f4c3fb: feat(spec): `RecordHighlightsField` declares `readonly` (#5176)
+
+  The object form of a `record:highlights` entry now declares an optional
+  `readonly: boolean`. It marks a highlight chip as non-editable — use it for
+  columns a hook or automation maintains, which must not be hand-edited from the
+  record header.
+
+  ```ts
+  {
+    type: 'record:highlights',
+    properties: {
+      fields: [
+        'name',
+        { name: 'supply_share', type: 'number', readonly: true },
+      ],
+    },
+  }
+  ```
+
+  **Why this is a spec change and not a renderer detail.** The renderer's
+  `HeaderHighlight` gate already refuses inline editing on a chip carrying
+  `readonly`, but the key was not declared here — and the object member is not
+  `.strict()`, so `RecordHighlightsField` **silently stripped** it:
+
+  ```
+  input   { fields: [ { name: 'supply_share', readonly: true, type: 'number' } ] }
+  parsed  { fields: [ { name: 'supply_share', type: 'number' } ] }
+  ```
+
+  That worked end to end only because per-component props are not parsed on the
+  live load path today (`PageComponentSchema.properties` is
+  `z.record(z.string(), z.unknown())`, so the bag rides through untouched). The
+  moment that gate is wired up, an authored `readonly` becomes either a silent
+  strip — a machine-owned column quietly editable again, with no diagnostic
+  anywhere — or a hard parse error. Declaring the key makes the authored
+  declaration and the enforced behaviour the same fact, which is what ADR-0049
+  asks for: it is enforced on arrival, not declared-and-inert.
+
+  For authors — including AI authors — the key now appears in the generated
+  component reference, and a misspelling (`readOnly`, `read_only`) is a wrong key
+  rather than a second de-facto contract the renderer happens to honour.
+
+  Purely additive: `readonly` is optional and no default is materialized, so an
+  entry that does not author it parses exactly as before, and the bare-string form
+  of a highlight field is unchanged.
+
+- 5c94f83: feat(spec): `SaveMetaItemResponseSchema` declares the whole save response — `version` / `seq` / `state` / `projectionApplied` (#5745)
+
+  `PUT /api/v1/meta/:type/:name` has always answered with more than the schema
+  admitted. The declaration stopped at `{ success, message? }` while the route
+  returns `{ success, version, seq, state, message }` — plus `projectionApplied`
+  when a projector is registered — so the contract described a proper subset of
+  the real body.
+
+  Because these are plain `z.object` schemas, the gap failed in the quietest way
+  available: `safeParse` stayed **green** and the undeclared keys were silently
+  **stripped**. Measured on `origin/main` before the change:
+
+  ```
+  raw keys      : ["success","version","seq","state","message"]
+  after parse   : ["success","message"]
+  STRIPPED      : ["version","seq","state"]
+  safeParse ok  : true
+  ```
+
+  `version` is the field this matters most for: it is the token the ADR-0008
+  optimistic-concurrency chain already runs on — echo it back as `If-Match` on
+  the next write and a concurrent edit returns 409 `metadata_conflict` instead of
+  silently overwriting. It was being carried on the wire with no contract behind
+  it, so a consumer that parsed the response lost exactly the value the OCC
+  handshake needs.
+
+  **Consumer-visible change.** Before, a `SaveMetaItemResponseSchema.parse()`
+  dropped the four fields and `SaveMetaItemResponse` could not name them at the
+  type level. Now they survive the parse and are typed:
+
+  - `version: string` — required. Opaque content hash; the ADR-0008 `If-Match`
+    token. Echo it verbatim, never parse it.
+  - `seq: number` (integer) — required. Metadata-event sequence number; orders
+    writes, but is not an OCC token.
+  - `state: 'draft' | 'active'` — required. The lifecycle the body landed in.
+  - `projectionApplied?: { success: boolean; error?: string }` — optional. The
+    ADR-0094 mutation-projector outcome, present only when a projector is
+    registered for that metadata type. Its absence means "no projector ran",
+    never "the projection failed"; a caller that needs the derived read model to
+    be live must check `projectionApplied.success` rather than trust the 200.
+
+  The three required fields are required because measurement says the producer
+  always emits them, not by assumption: `saveMetaItem` has a single success
+  return — the repository write path — and the REST route hands that object to
+  `res.json()` verbatim. A second, receipt-less legacy return would have forced
+  all three to be optional; it was proved unreachable and deleted in #5264 /
+  PR #5782, which is what makes `required` safe to state here.
+
+  No runtime behaviour changes: the route already returned these fields, and
+  nothing parsed the response through this schema. `client.meta.saveItem`'s
+  return-type annotation is deliberately left for the cli lane (#5545) so it is
+  written against the landed contract rather than ahead of it.
+
+- 73e576f: feat(lint,spec): SDUI 组件 props 接上解析闸门 —— `ComponentPropsMap` 不再是「声明了、从不被 parse」(#5068)
+
+  `PageComponent.properties` 是 `z.record(z.string(), z.unknown())` 这个开放口袋。
+  `PageComponentSchema` 自 ADR-0089 D3a 起是 `.strict()`,但**严格性不递归**:它守住
+  component 节点自己的键,`properties` 里面一个字都没人看。于是 `ComponentPropsMap`
+  里 31 个 typed props schema 从来没有被任何东西 parse 过(#4001 批 17 的 `no gate`
+  判定:载体活着、parse 缺席)。后果不是无害的 —— objectui 的 `SchemaRenderer` 会把
+  `properties` 整个 hoist 到节点上,再把 deny-list 之外的每个键 spread 成 React prop,
+  所以一个拼错的键既不被拒绝也不被丢弃:它一路走到渲染器,在那里被忽略,而作者拿到
+  的是一张成功回执。这正是 ADR-0078 要消灭的形状。
+
+  **新规则(两个诊断 id,均为 warning 级)**,落在 `@objectstack/lint`,按维护者对
+  #5068 的裁定走方向 A —— 在载体自己的授权门上分派解析,而不是改 `page` 协议的形状:
+
+  - **`component-props-unknown-key`** —— props schema 未声明的键,包括 props 包自身
+    这一层和它底下每一个 strip 姿态的对象。走的是 `lintUnknownKeysAgainstSchema`
+    (本次从 `@objectstack/spec` 导出,即 `lintUnknownAuthoringKeys` 用在每个 metadata
+    集合上的同一个 walker),所以 strip/strict/passthrough 的姿态规则与改名建议都是
+    单一实现,这里不重新推导一遍。
+  - **`component-props-invalid`** —— props schema 拒绝的值:类型不对、必填缺失、枚举
+    越界。
+
+  配套的一条契约细节:走到第二层。`readonly`(#5176)挂在 `RecordHighlightsField`
+  联合体的对象成员上,即 `fields[]` 数组项里面 —— authorable-surface walk 严格一层、
+  到不了那里(#5607 的更正)。本闸门到得了,并且两个方向都钉了测试:声明过的
+  `readonly` 必须静默,拼错的 `readOnly` 必须报出来并指名正确拼法。
+
+  **未注册 type 一律跳过**,这是必须语义而不是宽松:`PageComponentSchema.type` 是
+  `z.union([PageComponentType, z.string()])`,光是仓内 example 语料就授权了 10 种本
+  map 不承载的类型、共 87 个节点(`flex`、`grid`、`object-metric`、`object-chart`、
+  `record:line_items` …),它们的契约在 objectui 注册表和 ADR-0080 manifest 里。拿一个
+  不存在的 schema 去审判它们,只会把每一个都报成坏的。
+
+  **为什么本步只落 warning。**接上 parse 是执法的前置条件,不是执法本身(#5020 在隔壁
+  表面上的同一课)。闸门落在真实语料上会报 52 条:其中 34 条是三个已发布平台页把
+  `{ en, 'zh-CN' }` 内联多语言 map 写进了声明为纯 `z.string()` 的 `I18nLabelSchema`
+  (#5728,裁定中),另有 8 条是 `element:text.content` 上同一形状。今天就 gate 掉它们,
+  等于用平台自己都不遵守的声明去否掉平台自己的页面。warning 期的违例清单就是 error
+  升级的验收基线,升级本身是独立一步。
+
+  作者侧不变:`properties` 仍然照原样解析、原样保留,没有任何东西开始被拒绝 ——
+  `os validate` / `os build` / `os lint` 多了一类建议性诊断而已。存储路径(`saveMetaItem`
+  / REST `/meta`)仍然不校验 props 包,这一点被如实记录、未在本次修复。
+
+- c5a5996: fix(seed-loader): a roll-up summary left stale by a seed is now loud and counted
+
+  The loader recovers a post-write roll-up summary recompute that exhausts its
+  retries (`ERR_SUMMARY_RECOMPUTE`), and that recovery is correct: the rows WERE
+  written, so re-writing them would duplicate them (framework#3147). What was
+  wrong was the rank of the consequence. A roll-up summary is a **persisted
+  derived column** on the parent record, so after this the database is internally
+  inconsistent — the detail rows say one thing and the column that summarizes them
+  says another — and nothing recomputes it until some later write happens to touch
+  the same parent, which after a seed may never happen.
+
+  The entire event used to be one `warn` line reading _"records were written
+  (summary values may be stale)"_. It named no object, counted nothing, and left
+  `success: true` with every row counter clean, so no operator could see which
+  aggregate was wrong and no caller could detect it at all
+  ([#4998](https://github.com/objectstack-ai/objectstack/issues/4998)).
+
+  **It now logs at `error`**, naming the seeded object and the exact stale column
+  (`account.total_billed`), stating the consequence (the summary and its detail
+  rows disagree, nothing self-heals, and the seed still reports success) and the
+  remedy (fix the recompute error and re-run the seed, or trigger any write on the
+  affected parent to force a recompute), with the original cause attached. This is
+  the AGENTS.md "Degradation log levels" rule (#4632): persisted state and runtime
+  state disagreeing while everything looks normal is `error`, not `warn`.
+
+  **And it is counted** — `SeedLoadResult.summariesStale` and
+  `SeedLoaderResult.summary.totalSummariesStale`, mirroring `referencesDropped` /
+  `totalReferencesDropped`, which exists for the same shape one layer down ("the
+  row was written, something derived from it was lost"). A log line is not
+  something a caller can branch on; these counters are.
+
+  `success` deliberately stays `true`. It answers _"did the rows land"_, and they
+  did — every consumer treats `success: false` as "the write failed", so flipping
+  it would hand the protocol seed-apply surface a `false` with an **empty** errors
+  array and fail package/marketplace installs that in fact wrote every row. The
+  counter carries the signal instead; a caller that wants to treat a stale
+  aggregate as fatal reads `summary.totalSummariesStale > 0`.
+
+  Both counters are additive with a `0` default, so an existing producer or
+  consumer of `SeedLoaderResult` is unaffected — a payload written before this
+  release still parses, with `0`.
+
+- 23dba62: feat(spec,objectql): `strictReadonlyWrites` —— 让调用点选择「被剥离即响亮失败」(#5126)
+
+  写路径上的 readonly 剥离一直是**静默**的:调用方送来的只读字段被丢掉,写入照常提交并返回成功,该列保持原值。#4903(PR #5123)把这件事修得**可发现**(一条说清后果与出路的 WARN + `onFieldsDropped` 机器可读信号),但没能补上「出路」本身 —— 一个宁可让写入失败也不接受丢列的调用方(cron / 服务端插件)无处表达这个意图,因为选项键必须先落在 `packages/spec`。
+
+  本次按维护者裁定的 **B 方案**补上这一半:
+
+  - **`@objectstack/spec`**:`WriteObservabilityOptions`(`contracts/data-engine.ts`,`onFieldsDropped` 所在的**进程内** TS 契约)新增 `strictReadonlyWrites?: boolean`,默认关闭;`ERROR_CODE_LEDGER` 在 `@objectstack/objectql` 名下登记 `ERR_READONLY_FIELD_REJECTED`。
+  - **`@objectstack/objectql`**:`update` 在剥离接缝处兑现该语义 —— 置位且确有字段将被剥离时,在**任何驱动调用之前**抛出 `ReadonlyFieldRejectedError`(新导出,`code = 'ERR_READONLY_FIELD_REJECTED'`),因此**什么都不写**:不只是被拒字段,连本可存活的字段也不落库。单条与 bulk 两条路径同此。
+
+  三点值得单独说明:
+
+  - **默认行为零变化。** 不传(或传 `false`)时,剥离、`onFieldsDropped` 事件、提交结果与此前完全一致。这是一个 per-call 的选择加入项。
+  - **覆盖两种剥离原因。** 静态 `readonly`(#2948,仅对非 system 调用方生效)与 `readonlyWhen` 判定为真(#3042,对**所有**调用方生效,含 `isSystem`)。只覆盖前者会让本特性对它最想服务的调用方 —— 已声明 `isSystem: true` 的可信 cron —— 近乎失效:它恰恰豁免了静态剥离,却仍会静默丢掉被 `readonlyWhen` 锁住的列。两种原因累积进**同一个**异常,`fields` 是全量并集,`drops` 保留按原因的明细。
+  - **strict 是进程内语义,不跨 RPC / VDE 边界。** 它挂在 TS 契约而非可序列化的 `EngineUpdateOptionsSchema` 上,因此 REST / wire body **设不了**它:远程调用方既拿不到 `onFieldsDropped` 也拿不到 strict,其写入仍是「剥离后提交」。这是刻意的 —— 把写入拒绝开关放进客户端可填的袋子等于在安全相邻路径上开新攻击面(即被否掉的 A 方案)。契约测试钉住了这条边界。
+
+- fc5f536: fix(spec)!: `tenancy.tenantField` no longer defaults to `'tenant_id'` — an undeclared tenant column stays `undefined` and the driver's `organization_id` fallback is the single source of truth (#5315)
+
+  `TenancyConfigSchema.tenantField` carried `.default('tenant_id')`, so parsing
+  `tenancy: { enabled: true }` materialized `tenantField: 'tenant_id'` onto every
+  object that never asked for it. The platform's tenant column is
+  `organization_id` — the one the kernel injects, the one `rls.zod.ts`'s
+  `tenantPolicy()` defaults to, and the one the SQL driver actually scopes by.
+  The default was therefore a value **no consumer could use**: `computeTenantField`
+  in `driver-sql` honours a declared `tenantField` only when the object really has
+  that column, so the materialized `'tenant_id'` sent it looking for a column that
+  does not exist, the branch was skipped, and the fallback to `organization_id`
+  produced the right answer anyway. A declaration nobody reads (ADR-0078), spelling
+  a word the vocabulary rejects (ADR-0120 §Terminology fixes the authorable term at
+  `organization`, refusing `tenant`/`org`).
+
+  **What changes for an author**
+
+  |                                                           | before                                        | after                         |
+  | :-------------------------------------------------------- | :-------------------------------------------- | :---------------------------- |
+  | `tenancy: { enabled: true }` (parsed)                     | `{ enabled: true, tenantField: 'tenant_id' }` | `{ enabled: true }`           |
+  | effective tenant column                                   | `organization_id`                             | `organization_id` (unchanged) |
+  | `tenancy: { enabled: true, tenantField: 'workspace_id' }` | honoured when the column exists               | unchanged                     |
+
+  **The effective tenant column does not move.** That equivalence is pinned end to
+  end — parse through `ObjectSchema` and then resolve through the driver — by
+  `#5315 undeclared tenantField resolves to organization_id` in
+  `packages/drivers/driver-sql/src/sql-driver-tenant-scope.test.ts`.
+
+  **Type-level**: `TenancyConfig['tenantField']` widens from `string` to
+  `string | undefined`. Code that read the parsed value as a guaranteed string must
+  handle `undefined` — the correct fallback is `'organization_id'`, matching
+  `computeTenantField` and `tenantPolicy()`. No such reader existed in this repo,
+  `objectui`, or `cloud`: both real consumers already guarded (`driver-sql`
+  `computeTenantField` truthiness-checks it; `@objectstack/lint`
+  `authoredTenantColumn` falls back to `'organization_id'`).
+
+  Declaring `tenantField` explicitly is unchanged and still honoured — this only
+  stops the spec from inventing a value the author never wrote.
+
+- aac90a5: feat(spec,runtime,metadata-protocol,client)!: one closed capability vocabulary — every discovery producer emits every key (#5672)
+
+  `#4828` renamed the runtime dispatcher's top-level `features` map to the
+  canonical `capabilities`, which collapsed the _spelling_ split between the two
+  discovery producers. It did not touch the deeper one: the two went on filling
+  **disjoint key sets**.
+
+  | producer                                                                             | keys it filled                                                                        |
+  | :----------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------ |
+  | `getDiscovery()` — `@objectstack/metadata-protocol`, upstream of REST `/discovery`   | `comments` `automation` `cron` `search` `export` `chunkedUpload` `transactionalBatch` |
+  | `getDiscoveryInfo()` — `@objectstack/runtime` dispatcher, `/.well-known/objectstack` | `search` `websockets` `files` `analytics` `ai` `notifications` `i18n`                 |
+
+  Only `search` overlapped. `DiscoverySchema.capabilities` was an open
+  `z.record`, so both shapes parsed clean and no gate could see the split — while
+  `packages/client`'s `capabilities` getter **asserted** the result was a
+  `WellKnownCapabilities`. Against a dispatcher-served host
+  `client.capabilities.transactionalBatch` was therefore statically `boolean` and
+  actually `undefined`, as were `comments`, `cron`, `export` and `chunkedUpload`.
+
+  Per the maintainer's 2026-08-06 ruling, the vocabulary is now closed and
+  mandatory.
+
+  **What a consumer sees.** Before: which capability flags exist depended on
+  which kind of host answered, and a flag you were typed to receive could simply
+  be missing. After: every discovery response carries **every** flag, always a
+  boolean. A capability the host does not deliver is `enabled: false` — never an
+  absent key — so a client can read a flag without knowing whether it reached a
+  dispatcher, the REST endpoint, or anything else. `client.capabilities` no longer
+  asserts its own return type: it enumerates the spec's key list, so the type is
+  true by construction, and it reads a key an older server omits as `false`
+  (fail-closed, matching the wire rule).
+
+  **`@objectstack/spec`.** `WellKnownCapabilitiesSchema` becomes the one
+  vocabulary and gains the six flags that were previously the dispatcher's alone
+  (`websockets`, `files`, `analytics`, `ai`, `notifications`, `i18n`) — all six
+  were already real answers on the wire, so this declares them rather than
+  inventing them. `DiscoverySchema.capabilities` changes from an optional open
+  record to a **required closed object** derived from that vocabulary, one entry
+  per key. New exports: `WELL_KNOWN_CAPABILITY_KEYS` (the key list, derived from
+  the schema so nothing can hand-list a fourth dialect) and
+  `CapabilityDescriptorSchema` / `CapabilityDescriptor` (the `enabled` +
+  optional `features` / `description` entry shape, previously inline).
+
+  Required, not optional, is the `scoping` precedent read the other way round:
+  `scoping` is optional because only one producer can honestly answer it, whereas
+  every producer can answer `capabilities` — and an optional block would leave a
+  consumer back at `undefined` for every flag.
+
+  **Producers.** Each answers all thirteen keys from its own facts, with the basis
+  recorded per key in the code. The dispatcher now measures `comments` off the
+  `sys_comment` object in the registry it already resolves for its `/data` domain,
+  and `automation` / `cron` / `export` / `chunkedUpload` off the same service
+  predicates that gate its route advertisements. Its one honest `false` is
+  `transactionalBatch`: the atomic cross-object `/batch` route is mounted by
+  `@objectstack/rest`, and this dispatcher has no batch branch at all, so claiming
+  the runtime's `transaction()` here would advertise an endpoint the host does not
+  serve. `getDiscovery()` answers the six new flags off the service registry it
+  already reads, gated on serveability so a self-declared stub does not advertise
+  a capability it cannot back.
+
+  **Gates.** The three `discovery-schema-conformance.test.ts` suites built by
+  `#5682` and extended to `routes` by `#5743` gain a fullness criterion — every
+  vocabulary key present, every `enabled` a real boolean, no key outside the
+  vocabulary — with the allowance derived from the schema rather than written out.
+
+  **Upgrading.** A producer or fixture that builds a `DiscoverySchema`-shaped
+  document must now include a complete `capabilities` block; build it from
+  `WELL_KNOWN_CAPABILITY_KEYS` rather than by hand. Consumers need no change:
+  they receive strictly more keys than before, and any flag they already read
+  keeps its meaning. The lenient wire wrapper `GetDiscoveryResponseSchema` still
+  allows the block to be absent, so a response from an older server still parses.
+
+- 1e6ab15: feat(spec): `unique` scope vocabulary gains `'organization'` — scope is said, not positional (#4986, ADR-0120 D1/D6)
+
+  `UniqueScopeSchema` (field-level `unique` and `IndexSchema.unique`) widens from
+  `boolean | 'global'` to `boolean | 'global' | 'organization'`. Purely additive
+  in 17.x — no existing spelling changes meaning:
+
+  - **Field-level** `'organization'` is the explicit synonym of `true`
+    (per-organization uniqueness, identical materialization through the driver
+    predicates: `isUniqueDeclared` counts it, `isGlobalUnique` does not). Bare
+    `true` stays valid indefinitely; official examples and scaffolding emit
+    `'organization'` in new code (non-normative, ADR-0120 Resolved #2).
+  - **Declared-index** contract is now stated per word (ADR-0120 D1, amending
+    #3696): `'global'` = today's verbatim behavior — materialized over exactly
+    `fields`, no organization column injected; `'organization'` = the driver
+    prepends the NULL-safe organization key part
+    (`COALESCE(organization_id, '__global__')`, ADR-0120 D3) at registration —
+    materialization lands with #5030's driver PR, which this change must follow;
+    bare `true` = the deprecated positional spelling of `'global'` — warned in
+    17.x by lint `unique/unscoped-declared-index`, rejected at protocol 18
+    (#5082).
+  - **Rejected words carry the fix**: `'tenant'` and `'org'` are not accepted and
+    are not aliases — the parse error names `'organization'` (ADR-0120
+    §Terminology).
+  - New export `isOrganizationUnique` — detects the explicit `'organization'`
+    spelling, single source of truth for the declared-index distinction across
+    SQL/Mongo index sync.
+  - The `UniqueScopeSchema` doc block's false single-tenant exemption ("the
+    tenant column is constant, so the composite index degenerates to the
+    single-column one" — falsified by #5030: the constant is NULL and SQL UNIQUE
+    is NULL-distinct) is replaced with the D3 truth (NULL bucket + COALESCE).
+
+### Patch Changes
+
+- 28ad90e: feat(types,cloud-connection,lint,cli): ADR-0120 17.x 收尾 —— `isolated` 安装期姿态硬门(D5e)、D5c 重拼写 advisory、成文契约扫荡与三姿态 conformance (#5081)
+
+  ADR-0120 17.x 波的第三块,也是最后一块。前两块已在 main 上:#5212(driver 侧
+  D3+D4 —— `COALESCE(organization_id, '__global__')` 物化、drift 两侧同步、重复预检)
+  与 #5208(spec 词汇 `'organization'` + D5a/D5b lint)。本次补齐三件事:安装期的
+  姿态决策点、剩余的成文契约、以及把「一个 app 包跑遍三种姿态」从假设变成测试。
+
+  **D5e —— 装进 `isolated` 环境时的硬门。** 词汇本身是姿态无关的:作者说的是业务
+  边界(`'organization'` 一个组织一份 / `'global'` 整个安装一份),没有任何索引形状
+  读姿态。唯一的残留在一个方向上:`isolated` 下组织就是**不同客户**,此时 app 业务
+  对象上的 `'global'` 唯一既跨客户过度约束,又变成跨客户的存在性预言机(S10/S14)。
+  维护者裁定这是**硬门而非 advisory**:把带 `'global'` 唯一(非 `sys` 对象)的 app
+  装进 `isolated` 环境会**停下来并逐索引列出**,安装者(通常是 AI agent)要么确认它
+  确实是平台级的,要么改写为 `'organization'`;确认按 ADR-0104 attestation 风格
+  留痕在安装清单里(`InstalledManifestEntry.globalUniqueAttestation` —— 确认了什么、
+  谁确认的、何时、在哪个姿态下问的),**之后不复问**。
+
+  - 停下的安装**什么都不留**:先于 hot-register 和任何 ledger 写入,所以作者改完
+    元数据可以直接重试,不需要先卸载。
+  - 逐索引确认是有牙齿的:`confirmGlobalUniques` 收 `true` 或明确的 id 数组,只确认
+    其中一条仍会在剩下的那条上停住。
+  - 升级引入的**新**约束会被问,老的答案继续算数。
+  - 另一个姿态下给出的确认**不算同意** —— `isolated` 那个问题在 `single` 下从未被
+    问过,所以按「未确认」处理(唯一不会静默放行跨客户约束的方向)。
+  - ⛔ **永不做成启动期告警**(#4884 纪律)。boot 时的 rehydrate 不评估此门;门够不到
+    的两类存量 —— 门禁上线前的安装、装后姿态变更的环境 —— 由 `os doctor` 与
+    `os migrate plan` 的 advisory 形态覆盖。
+
+  判定里有三条是承重的,别「简化」掉:声明索引上的裸 `unique: true` **算**(D1 说它
+  就是 `'global'` 的位置式拼写,排除它等于让整个 17.x 可以靠拼写绕过);字段级
+  `true` **不算**(它是 `'organization'`,永久合法);`sys_`/`base_` 对象**不算**
+  (S5 那批引擎幂等键天然就是平台级的,每次安装都问一遍就是 #4884 的误报类)。
+
+  CLI: `os package install` 新增 `--confirm-global-uniques`,并把 409 渲染成可读的
+  逐条清单而不是一句 "Install failed (409)"。
+
+  **D5c —— 遗留手写组织复合索引的 advisory。** 新规则
+  `unique/legacy-organization-composite`:声明的唯一索引自己列出了组织列
+  (`{ fields: ['name','organization_id'], unique: true }`)—— 这是词汇出现之前手写
+  per-organization 的写法。它读起来像「每组织唯一」,物化出来却是普通复合索引,而
+  SQL UNIQUE 是 NULL-distinct 的:组织列为 NULL 的行上它**什么都不约束**(#5030),
+  在单组织部署上那就是每一行。改写成 `unique: 'organization'`(`fields` 原样保留,
+  driver 会把已列出的组织列**就地**变成 NULL-safe 形式)正是补上这个洞的动作。
+  **永远只是 advisory,永远不自动修**:老拼写永久合法、零强制 drift,而 opt-in 是
+  真实的物理收紧,要走 D4 的 `recreate_index` + 重复预检。
+
+  **D6 —— 成文契约扫荡。** `content/docs/data-modeling/indexing.mdx` 的
+  §Two ways to say "unique" 全节按新词汇重写(含 `os:check` 代码块);
+  `content/docs/protocol/objectql/schema.mdx` 的 §Uniqueness and tenancy 重写为
+  §Uniqueness and scope —— 其中那句「单租户部署不受影响,租户列是常量,复合索引
+  退化为单列索引」是 #5030 **证伪过的原话**,现已替换为 D3 的 NULL-safe 事实;
+  `content/docs/deployment/cli.mdx` 的 `replace_unique_index` / `recreate_index`
+  条目补上 NULL-safe 形状与重复预检;`content/docs/references/**` 经
+  `gen:schema && gen:docs` 再生成,未手改。
+
+  按 ADR-0120 Resolved #2 的非规范性引导(官方示例/脚手架/生成器在新代码中输出
+  显式拼写),`skills/objectstack-data/**` 的索引与校验规则整体扫过:声明索引一律
+  说清 scope,并新增一节完整讲 `'organization'` 的 NULL-safe 语义与「永远不写姿态」。
+  顺带修掉那里长期使用的 `tenant_id` —— 平台的列叫 `organization_id`。
+  `examples/**`、`create-objectstack` 模板与 `os generate` 经核查**根本没有声明任何
+  唯一约束**,故无可扫;这是核查结论,不是遗漏。
+
+  **三姿态 conformance(ADR §Acceptance tests)。** 同一个 fixture app 在
+  `single | group | isolated` 三姿态下启动,逐 S 行用**真实的违规插入**断言 enforcement
+  (S1/S2/S3/S4/S5/S6/S7/S8/S9/S11/S12),并逐姿态捕获物化出的索引键,断言三者
+  **逐字节相同** —— 「没有任何索引形状读姿态」这句话一旦有两者不同就是假的。相同性
+  断言配了一条正向断言(对着期望的键形状),这样「三次都什么都没建」不会读成「一致」。
+  外加 ADR 只要的那一条 transition smoke:在 `single` 下建库、`isolated` 下重新打开,
+  drift op 为零。
+
+  对既有部署的影响:除新增的安装期确认外,本次不改变任何已有物化行为。字段级
+  `unique: true` 一如既往合法。
+
+- f8644c7: Put the 44 pre-helper alias tables under the alias-integrity gate — including the
+  collision claim they were never measured on.
+
+  `alias-integrity.test.ts` (#5013) judges alias tables built by `strictObject`,
+  which registers each one alongside the `.shape` it makes claims about. The 44
+  call sites that predate that helper call `strictUnknownKeyError` directly and
+  hand it a transcribed `knownKeys` array; with no shape to register, they sat
+  outside every claim the gate makes.
+
+  `strictUnknownKeyError` now records its own `{ surface, knownKeys, aliases,
+guidance }` in an internal registry, and the gate judges that batch too. The
+  registration lives in the factory, so no schema module changed.
+
+  What each claim is worth on this batch differs, and the gate says so rather than
+  implying uniform coverage:
+
+  - **alias key is not a known key** and **alias target is a known key** are
+    answered against the transcribed array. If that array has drifted from its
+    schema, both answers inherit the drift — the gap `strictObject` exists to
+    abolish, and only migrating a call site closes it (#5593).
+  - **no two alias keys share an `aliasProbe`** (#5481) loses nothing: a collision
+    is a property of the table alone. These tables were **unmeasured** on it, not
+    clean — #5481 postdates the measurement recorded in #5483 — and the sweep they
+    had never had comes back clean at 52 tables.
+
+  The target claim found a real one on its first run: `ui/app.zod.ts` shares four
+  "start expanded" aliases across all nine navigation-item variants, but `expanded`
+  is declared on the `group` variant alone, so on the other eight the suggestion
+  names a key that variant also rejects — the second rejection this campaign
+  exists to end. Filed as #5555 (the fix rewrites author-facing message text) and
+  pinned here shrink-only, structurally, so nothing else can enter the tolerance.
+
+  Two supporting pieces, both deliberately visible rather than implicit: the walk
+  now forces error maps that build themselves on first use (`data/object.zod.ts`
+  defers its map around a temporal dead zone, and would otherwise never register),
+  and the six prose alias targets on `ui/app.zod.ts`'s navigation items —
+  `type: 'url' (with url)` and friends, which name a variant rather than a key —
+  are an enumerated allowlist scoped to that surface, with a staleness check that
+  fails if an entry stops being used.
+
+  The shrink-only ratchet at 44 is unchanged. What it discourages — a new call
+  site minting a fresh second copy of a key list — is exactly as undesirable as it
+  was before these tables gained a guard.
+
+- 306ca50: fix(spec): unknown-key suggestions no longer point authors at keys the schema rejects (#5013)
+
+  An `aliases` table on an authoring schema is a **claim about that schema**, in
+  two halves: that the key it is filed under is one the shape _rejects_ (an alias
+  is consulted only from the `unrecognized_keys` path, so a key the shape declares
+  can never reach it), and that the key it prescribes is one the shape _accepts_.
+  Nothing checked either half, and both were false on `main`.
+
+  Writing `filter` on a report produced:
+
+  ```
+  Unrecognized key(s) on this report: `filter`. … Did you mean `filter` -> `filters`?
+  ```
+
+  and taking that advice produced a **second** rejection — `ReportSchema` declares
+  neither `filter` nor `filters`, only `runtimeFilter` — this time with no
+  suggestion at all. That is the exact failure the unknown-key strictness work
+  exists to remove, shipped by its own fix, and it is worst for AI authors whose
+  only signal is whether the parse complained.
+
+  **What changed** — no authorable key was added or removed, so nothing that
+  parsed before stops parsing; only the guidance an author gets when a key is
+  rejected:
+
+  - `ReportSchema` — `filter`, `filters`, `where` and `criteria` now all name
+    `runtimeFilter`, matching `JoinedReportBlockSchema`'s table verbatim so a
+    report and its sub-reports correct the author identically.
+  - `EmailTemplateDefinitionSchema` — `html`/`content` name `bodyHtml`, `text`
+    names `bodyText`, and `from`/`sender` name `fromOverride`. All five previously
+    named `body` / `fromAddress`, neither of which the schema declares.
+  - `SkillSchema` — `trigger` no longer renames onto `triggers` (never a key).
+    It now carries a prescription instead, because the correct answer is a split:
+    routing intent belongs in `triggerConditions`, natural-language intent in
+    `description` / `instructions`. A rename would have landed a phrase in an
+    array-of-conditions slot and been rejected on the value instead of the key.
+  - Six entries filed under keys their own schema already declares — and which
+    therefore could never run — are gone: `columns` and `chart` on `ReportSchema`,
+    `measures` and `filter` on `DatasetSchema`, `body` on `ActionSchema`.
+
+  **What keeps it true** — `strictObject` now records each shape it builds, and
+  `alias-integrity.test.ts` judges every one of the 235 authoring surfaces in the
+  package against the runtime `.shape` it makes claims about. Reading the runtime
+  shape rather than the source is what makes it work: shapes spread
+  (`...MetadataProtectionFields`), ten alias tables are assembled rather than
+  written as literals, and two different schemas share the surface string
+  `'this field group'` — a source-literal reader is wrong or blind on all three.
+  An alias pointing at a **tombstone** is caught too, which the suggester's own
+  `knownKeys` filter cannot do, since the alias table is consulted before that
+  fallback runs.
+
+- 978fed2: fix(analytics,rest): five dataset refusals declare `DATASET_INVALID` / 400 themselves, and the route's message-sniffing list shrinks to one entry (#5367)
+
+  `POST /analytics/dataset/query` answered `400 DATASET_INVALID` for six error
+  families because the route recognised their **prose**, not because the errors
+  said anything about themselves. #5352 gave the catch an ADR-0112 envelope branch
+  (`error.code` + a 4xx `error.status`, read first) and had to leave a hardcoded
+  list of message substrings behind it, since all six producers were still bare
+  `throw new Error(…)`:
+
+  ```
+  /not declared in the dataset|not backed by a declared relationship|
+   not supported by the v1 dataset runtime|read-scope-sql|
+   not a selected dimension or measure|is not a subset of the selected dimensions/
+  ```
+
+  That made the HTTP status of six families a property of their wording.
+  Rephrasing `dataset-compiler`'s "is not declared in the dataset's `include`" —
+  no logic change — moved that refusal from 400 to 500, i.e. re-opened #5352 for a
+  different family, and no test and no gate would have gone red. Prime Directive
+  #12 permits an accommodation like that only while it is declared, loud, tested
+  **and removable on a schedule**; #5366 delivered the first three and nothing
+  carried the fourth.
+
+  **Five producers now declare their own verdict.** A new
+  `dataset-refusal.ts` in `@objectstack/service-analytics` exports
+  `datasetInvalidError` — the same shape as that package's existing
+  `invalidFilterError` (`INVALID_FILTER` / 400) and `assertDimensionFields`
+  (`INVALID_FIELD` / 400) — and five sites throw through it:
+
+  - `dataset-compiler.ts` — a measure whose aggregate the v1 runtime cannot lower;
+    a dimension/measure traversing a relationship path the dataset never declared
+    in `include`;
+  - `dataset-executor.ts` — an `order` key that is not a selected dimension or
+    measure; a `totals` grouping that is not a subset of the selected dimensions;
+  - `native-sql-strategy.ts` — a join outside the dataset's declared allowlist.
+
+  Their five entries are gone from the route's list, which is now a single
+  `read-scope-sql` test.
+
+  **`read-scope-sql` deliberately stays.** Its ten fail-closed refusals are RLS
+  read-scope lowering failures whose inputs are an admin-authored policy and a
+  compiler-generated join alias — not caller input — so `DATASET_INVALID` ("your
+  request is invalid") may well be the wrong verdict and choosing the right one is
+  a separate judgement, still tracked by #5367. Deleting the entry before that
+  judgement lands would regress those ten from `400 DATASET_INVALID` to 500.
+
+  **No outward behaviour change for the five.** They answered
+  `400 DATASET_INVALID` before and answer `400 DATASET_INVALID` now, with the same
+  message; what changed is the mechanism, from message-matching to the producer's
+  own declaration. The one visible difference is for a bare `Error` that merely
+  _resembles_ one of those messages: it is no longer promoted to a 400. That is the
+  point — a phrase is no longer a classification.
+
+  `DATASET_INVALID` is registered in `ERROR_CODE_LEDGER` under
+  `@objectstack/service-analytics` as well as `@objectstack/rest` (provenance, per
+  ADR-0112 D3; the code itself is unchanged and the union does not grow), and the
+  constructor types it as `RegisteredErrorCode` so an unregistered code is a
+  compile error rather than a body some route rejects at runtime.
+
+  Coverage: `dataset-refusal-envelope.test.ts` (service-analytics) pins each of the
+  five refusals against its real producer — the refusal SET first, green before and
+  after, then the envelope; `analytics-dataset-refusal-envelope.test.ts` (rest)
+  drives all five end-to-end through a real `AnalyticsService` with positive
+  controls on both the aggregate and raw-SQL paths; and
+  `analytics-filter-refusal-envelope.test.ts` pins the deletion in both directions
+  — the five messages answer 400 when enveloped and 500 when bare, so re-adding a
+  regex entry turns it red.
+
+- cfc293f: fix(service-analytics): 空 `$and` / `$or` 按布尔单位元归约,两个编译器与五后端对齐 (#5322)
+
+  同一个仓库对空组合子曾有两个对立答案:五个 `FILTER_LOGIC_CASES` 后端
+  (`driver-sql` #5134/PR #5243、`driver-memory`、`formula`、`driver-sqlite-wasm`、
+  `driver-mongodb` #5239)把 `{ $and: [] }` / `{ $or: [] }` 归约成布尔单位元,而
+  service-analytics 的两个编译器 —— `read-scope-sql.ts` 的 `compileNode` 与
+  `filter-normalizer.ts` 的 `buildNode` —— 成文地 fail-closed 抛错("An empty
+  combinator has no defensible reading…"),并有 pin 测试钉住。2026-08-04 维护者拍板
+  (#5322)取单位元,本次把两处对齐:
+
+  - `{ $and: [] }` = TRUE(全部行,AND 单位元);`{ $or: [] }` = FALSE(零行,OR
+    单位元)。嵌套可归约:空组合子作 `$or` 分支时按 TRUE 吸收/FALSE 退出析取,作
+    `$not` 操作数时取反(`{$not: {$and: []}}` = 零行、`{$not: {$or: []}}` = 全部
+    行)。`{}` = TRUE 与 `{ $not: {} }` = 零行两格已由 #5297(read-scope)/#5325
+    (normalizer)先行落地,本次连同这四格由同一张一致性表钉住。
+  - **迁移含义**:过去发出空组合子的调用方收到的是抛错(REST 面上是一次失败的请
+    求);现在按上表求值。`{ $or: [] }` 在 RLS/图表场景是 fail-closed 的 —— 析取列
+    表循环出零项时隐藏全部行,而不是放行全表。写作期对字面量空组合子的响亮拒收另立
+    #5330(publish/lint),不在运行期。
+  - **没有放宽的部分**:非数组的 `$and`/`$or`、非对象的分支、非对象的 `$not` 操作数
+    仍然抛错(#5325 的形状拒收原样保留)。归约让「无约束」成为有意义的裁决,静默把
+    畸形分支读成 TRUE 会让垃圾析取项吸收 `$or` 而放宽查询,所以畸形形状保持响亮。
+  - 归约与 #5146/#5325 的 NULL-safe `$not` 重写的组合语义是「先归约、后 NULL-safe」
+    —— 常量归约出的单位元不受重写影响,幸存的叶子照常加守卫,有测试钉住。
+  - `packages/spec`:`FILTER_LOGIC_CASES` 补四条布尔单位元行(空 `$and`、空 `$or`、
+    `{}` 析取项吸收、`{$not: {}}`),两个 analytics conformance suite 与五后端从此
+    被同一张表钉住这四格。
+
+- de70b42: analytics: `$ne` / `$nin` / `$notContains` in a dashboard `where` keep the rows that have no value
+
+  Second batch of the #5298 ruling, after PR #5962 landed it on `driver-sql`,
+  `read-scope-sql` and `formula`. An analytics filter meaning "not this" now
+  returns the rows whose column is empty, the same answer every other backend
+  gives — a `stage != 'won'` widget shows the deals with no stage set.
+
+  The Cube face was the last surface still splitting on it, and it split three
+  ways for one filter. Measured on the package's own fixture before the change,
+  for `{stage: {$ne: 'won'}}` with rows 3-4 carrying a NULL `stage`:
+
+  | compiler                            | was     | now     |
+  | ----------------------------------- | ------- | ------- |
+  | `NativeSQLStrategy` raw SQL         | `2`     | `2,3,4` |
+  | `ObjectQLStrategy` display-SQL echo | `2`     | `2,3,4` |
+  | `ObjectQLStrategy` engine condition | `2,3,4` | `2,3,4` |
+
+  The engine column was already right — because `driver-sql` guards for itself
+  since #5962, not because the analytics layer did — so which rows a widget drew
+  depended on which compiler downstream caught the leaf, and the `/analytics/sql`
+  echo described a narrower query than the one that ran.
+
+  `filter-normalizer` now emits the guard as tree STRUCTURE (an `or` of the null
+  predicate with the comparison) rather than as a SQL trick in one strategy, so
+  all three compilers of that tree produce one predicate and none of them needs
+  to know the rule. Which operators are guarded is decided by the polarity table
+  the `$not` rewrite already consults, not by a second list of operator names:
+  positive comparisons (`$eq`, `$in`, `$contains`, the ordering family) compile
+  byte-identically to before, `$ne: null` stays `IS NOT NULL`, an empty `$nin`
+  stays the TRUE constant, and `{$not: {stage: {$ne: 'won'}}}` still means
+  "stage is won" rather than widening.
+
+  `FILTER_LOGIC_CASES` is unchanged: the `$ne` and `$not` null rows enrol in
+  #5903's PR, which clears the last backend (`driver-turso` remote). The spec
+  table's measured blocker matrix drops the Cube row it no longer describes.
+
+- fb3d99b: fix(analytics,rest)!: an RLS read-scope lowering failure is a `500`, not the caller's `400` — and its policy detail no longer reaches the response (#5367)
+
+  **Observable behaviour change — read this if you alert, retry, or assert on status.**
+  A request whose dataset carries an RLS read scope that `read-scope-sql.ts` cannot
+  lower used to answer `400 DATASET_INVALID` with the refusal message echoed
+  verbatim. It now answers `500 ANALYTICS_QUERY_FAILED` with the message withheld
+  (`"Internal server error"`); the full text goes to the server log. Monitoring that
+  counted these as client errors will see a 4xx disappear and a 5xx appear, and a
+  client retrying on 5xx will now retry a request that cannot succeed until an
+  administrator fixes the policy. Both follow from the correction below and are
+  stated rather than buried.
+
+  ## What was wrong
+
+  These ten fail-closed refusals were the last family `/analytics/dataset/query`
+  classified by **prose** — the final entry of the hardcoded message-substring list
+  #5352 introduced, which #5367's first PR had already shrunk from six entries to
+  one. Two defects in one verdict:
+
+  - **Misattribution.** `compileScopedFilterToSql(filter, alias)` receives an RLS
+    `FilterCondition` the security service compiled from an **administrator's**
+    sharing rule / permission set, and a join alias the **dataset compiler**
+    generated. Neither is caller input — the caller's own predicate goes through
+    `filter-normalizer.ts` and has answered `INVALID_FILTER` / 400 since #5352. So
+    what can arrive here is a broken policy, or drift between two of our own
+    components (#5557's `$regex` was literally the second case). For this request's
+    caller both are a **server** fault; `400` told them to fix a request that was
+    never wrong and kept the real fault out of 5xx alerting.
+  - **Disclosure.** A 400 echoed the message, so
+    `unsafe field identifier "secret_policy_field"` and
+    `unsupported operator "$regex" on "owner_email"` handed a tenant the field names
+    and comparands of the RLS policy governing them.
+
+  The maintainer ruled on 2026-08-06 (option B on #5367's decision card; option A
+  was `READ_SCOPE_INVALID` / 422, rejected because no consumer reads a code on this
+  path, a 4xx misreports a condition the client cannot fix, and 422 would have left
+  the disclosure question to be re-decided message by message).
+
+  ## What changed
+
+  - `read-scope-sql.ts` gains a module-local `readScopeCompileError` — the twin of
+    `filter-normalizer.ts`'s `invalidFilterError`, and likewise **the only way the
+    module refuses**. All ten sites carry `READ_SCOPE_COMPILE_FAILED` / **500**.
+    `:104`'s alias-vs-field split (option C on the card) collapses under B: both
+    branches answer the same verdict, pinned so the collapse is a recorded decision.
+  - `rest-server.ts` loses branch ② entirely. **The message-sniffing mechanism is
+    fully retired** — nothing in this catch reads prose any more, and #5367's
+    Prime-Directive-#12 retirement schedule ("declared, loud, tested AND removable
+    on a schedule") is paid off.
+  - The route's 5xx branch now withholds the message of any producer that
+    **declares** a server fault (`status >= 500` with a `code`). This was needed
+    rather than inherited: `looksLikeInternalErrorLeak` (#3867/#5520) is a heuristic
+    over SQL/driver _phrasing_, and measured, every read-scope message returns
+    `false` from it — so retiring the list alone would have moved the policy content
+    from a 400 body into a 500 body instead of out of the response. Teaching that
+    heuristic to recognise `[read-scope-sql]` would have been _more_ message
+    sniffing, so the rule keys on the ADR-0112 envelope instead. **Undeclared** 5xx
+    errors keep #5667's tiering, so a self-authored fault ("no strategy can handle
+    query …") stays readable.
+  - `READ_SCOPE_COMPILE_FAILED` is registered in `ERROR_CODE_LEDGER` under
+    `@objectstack/service-analytics` (ADR-0112 D3) and typed as
+    `RegisteredErrorCode` at the constructor, so an unregistered code is a compile
+    error. It is legible on the wire through the sibling `/analytics/query` exit,
+    which puts a thrown `err.code` in `error.details.code` (#3842).
+
+  **Which inputs are refused did not change.** No refusal condition moved: nothing
+  that used to lower now throws, and nothing that used to throw now lowers. That is
+  pinned input-by-input — refusals _and_ accepted read scopes with their compiled
+  SQL and bind params — in `read-scope-refusal-envelope.test.ts`, which is green both
+  before and after; only the envelope assertions move.
+
+  Coverage: `read-scope-refusal-envelope.test.ts` (service-analytics) drives all ten
+  sites through the real compiler; `analytics-read-scope-refusal-envelope.test.ts`
+  (rest) drives five policy shapes end-to-end through a real `AnalyticsService`,
+  asserting the 500, that the body contains no policy detail, and that the withheld
+  text is present in the log — plus a positive control and both sides of the
+  declared-vs-undeclared withhold.
+
+- f1cc3a3: fix(spec): stop offering retired `app` keys in the metadata form, and make the reconciliation gate see tombstones (#5280)
+
+  The `app` authoring form rendered **eight** controls for keys `AppSchema` had
+  already retired to `retiredKey()` tombstones in 17.0.0 — `version`, `homePageId`,
+  `objects`, `apis`, `sharing`, `embed`, `mobileNavigation` and `aria`. A tombstone
+  is `z.never().optional()`, so filling one of those controls did not lose the
+  value quietly: it failed the **entire save** with the key's removal
+  prescription. The controls are gone, each with a comment in place naming where
+  the capability went (`manifest.version`; the first `navigation` item by `order`
+  plus `isDefault`; `defineStack({ objects })`; `defineStack({ apis })`;
+  `FormView.sharing` for both public access and embedding; the component that
+  renders the DOM node for `aria`).
+
+  Nothing about the contract changes — every one of these keys was already
+  rejected at parse. What changes is that an author is no longer shown a control
+  that can only produce a 422.
+
+  **The reconciliation gate now judges the right thing.** #3786's
+  `metadata-form-zod-reconciliation.test.ts` asked whether an offered key was
+  `∈ shape`. That was the same question as "may the author write this" until
+  `retiredKey()` existed: a tombstone **deliberately stays in the shape** so the
+  removal can carry its own upgrade prescription, so every one of those eight keys
+  read as "the Zod accepts it" and the gate stayed green over all of them. It now
+  asserts `∈ shape` **and not a tombstone**, in both directions — a retired key
+  may not be offered, and its absence needs no ledger entry to excuse it. The
+  detector reads the schema node (`z.never()` under the optional wrapper), never a
+  list of key names, mirroring `isRetired()` on the JSON-Schema side of
+  `build-schemas.ts`. The next `retiredKey()` retirement that forgets a form now
+  fails this test instead of reaching an author.
+
+  Retiring an authorable key already required pruning its form input; that step is
+  now enforced rather than remembered.
+
+- 553a47f: fix(spec): `areas[].requiredPermissions` 的退役处方改口径 —— 项级闸门在**两棵树**都由服务端剥离(#4749)
+
+  `AREA_REQUIRED_PERMISSIONS_RETIRED` 是作者写错 area 级键时唯一能读到的文字(strict
+  schema 的 unknown-key 报错正文)。它此前写着:
+
+  > Items nested under `areas[]` are gated in the shell only — the server does not
+  > walk `areas` — so anything that must never reach the browser belongs in the
+  > top-level tree, or in its own app.
+
+  这句话在 #4722 之后已经过时。`filterAppForUser` 现在对每一棵 `areas[].navigation`
+  跑**同一个** `filterNav`,所以导航**项**上的 `requiredPermissions` / `requiresService`
+  在顶层树和 area 内部被同等强制,被闸住的条目(连同它的 `objectName` / `pageName` /
+  `componentRef` 目标)根本不会进入 `/meta` 响应体。
+
+  方向上这是「过度保守」而非不安全 —— 它劝作者把敏感项挪到顶层树,那仍然可行 —— 但它错了,
+  而且错在**说给作者听的**那一份上:一个本可以就地把 `requiredPermissions` 写在 area 内部项
+  上的作者,会被这段话劝去重构导航树。
+
+  处方正文改后陈述当前事实,并保住 #4722 **没有**改变的那一半非对称性:`visible`(CEL)与
+  `requiresObject` 在任何层级**依然只在客户端求值**(服务端跑 CEL 需要读层没有的 `user`
+  绑定上下文)。所以「必须永不到达浏览器」的东西写 `requiredPermissions`,不要写 `visible`
+  —— 这一条在 #4722 之后反而更容易被误读,因此写进了正文并单独钉了 pin。
+
+  同一次改口径也覆盖姊妹处方 `AREA_VISIBLE_RETIRED`(作者写错 `areas[].visible` 时读到的那
+  份)。它此前把服务端强制的落点枚举成「on the app itself, or on items of the app's top-level
+  `navigation` tree」—— 不是假话,但 #4722 之后这份**枚举**漏了 `areas[].navigation` 的项,
+  效果与上面那句相同:一个已经站在 area 内部、本可以就地把闸门写在该 area 项上的作者,被劝去
+  重构导航树。现在两处落点都列全。
+
+  ⚠️ 这条**没有**改变 `visible` 自身的口径:项级 `visible` 依然是 CEL、依然只在浏览器里求值,
+  #4722 没有碰这一半。正文里把两者的分工写死 —— `visible` 隐藏的是**已经发出去**的条目,
+  `requiredPermissions` 才让条目根本不被发出 —— 因为作者是攥着一个 CEL 表达式走到这条报错前
+  的,「就近改写成项级 `visible`」正是此刻最顺手也最危险的那个落点。
+
+  退役裁决本身不动:被强制的是 area **内部的项**,area **级**键(`areas[].visible` /
+  `areas[].requiredPermissions`,#4651)保持退役,没有复活。
+
+  行为零变化 —— 改的是两条报错正文与它们的 pin 断言,以及 `app.zod.ts` 里同一段已随 #4722
+  过期的说明性注释。
+
+- a3a884d: fix(spec): re-anchoring `authorable-surface.base.json` is an explicit act, not a build side effect (#5358)
+
+  `packages/spec/authorable-surface.base.json` is the in-tree anchor the #4650 deletion gate
+  falls back to where `origin/main` is out of reach (#5235). It is not a projection of this
+  package's source — it is a snapshot of an **upstream** commit, and it is the baseline
+  precisely because the commit under test cannot rewrite it.
+
+  Until now every `gen:schema` run rewrote it whenever it had drifted from the git-resolved
+  baseline. `gen:schema` is `pnpm build`'s first step, so this fired on any build of any
+  package that merely has `@objectstack/spec` in its dependency closure, and on `check:docs`
+  (whose first step is `gen:schema`). Three developers hit it independently, from three
+  unrelated tasks:
+
+  - a plain `pnpm build`: `baseRev` advanced to HEAD, **−110 keys**;
+  - `pnpm --filter "@objectstack/cli^..." build`: the same 110;
+  - `pnpm --filter "@objectstack/service-automation^..." build`: `baseRev` advanced, +3 keys.
+
+  The 110 were the `ui/ComponentAnimation` family that had just been retired. An anchor
+  advanced past a retirement cannot see that retirement any more — and the gate is green
+  before _and_ after, because both states are internally consistent. All three were caught
+  only by reading `git status` line by line before committing; a `git add -A` would have
+  carried the moved baseline into a PR about something else.
+
+  The anchor now moves only in a mode of its own:
+
+  ```bash
+  pnpm --filter @objectstack/spec gen:authorable-surface-base   # build-schemas.ts --update-base
+  ```
+
+  - `gen:schema` and any build: never write it. A lagging anchor prints one ℹ️ line saying so,
+    naming this command — lag was already not an error (on `main` the merge base is HEAD, so
+    the file necessarily trails its own surface by one PR).
+  - `check:authorable-surface`: unchanged, still strictly read-only, and still fatal when the
+    committed anchor is missing, malformed, or inauthentic.
+  - `--check --update-base` is refused: a check that repairs what it detects can never report it.
+
+  Nothing about anchor **authenticity** changes: `baseRev` must still be an ancestor of
+  `origin/main` with keys matching that commit's `authorable-surface.json`, the anchor is
+  still written only from a git-resolved baseline (never from the build being checked), and
+  the write still happens after the deletion gate has adjudicated the run, so the explicit
+  mode cannot walk the baseline past an unproven deletion either.
+
+- cfed092: fix(spec): `--update-base` re-anchors forward or refuses — never backwards, never mid-merge (#5370)
+
+  #5358 made re-anchoring `packages/spec/authorable-surface.base.json` an explicit act
+  (`gen:authorable-surface-base`). It settled **when** the anchor may be written, not **where
+  from**: the baseline is still `merge-base(HEAD, origin/main)`, and that is not always ahead
+  of the anchor already committed.
+
+  The reported way in is a stopped merge. Until the merge is committed, `HEAD` is the branch
+  tip from _before_ it, so the merge base is the branch's **old fork point** rather than the
+  main tip being merged in, and re-anchoring there rolls `baseRev` backwards. Measured on the
+  #5312 sync relay: `1c3da1f` → `5aae790`, returning the 109 keys #5321 had just retired.
+
+  Nothing could catch it. The older rev is a genuine `origin/main` ancestor and the keys
+  written are that commit's surface verbatim, so the regressed file is **authentic** —
+  `verifyCommittedSurfaceBase`, `check:authorable-surface` and the pre-commit `os-regen` guard
+  are green before and after. The only trace is a reverse `baseRev` move in the diff, which
+  reads like the #4650 attack shape and was written by the generator itself.
+
+  Two refusals, both in `--update-base` only:
+
+  - **Mid-merge**: `MERGE_HEAD` present (resolved via `git rev-parse --git-path`, so linked
+    worktrees are handled) refuses before a single schema is generated, the way
+    `--check --update-base` already did, and prescribes the remedy — commit the merge, then
+    re-anchor. `scripts/regen-artifacts.mjs` states the same rule for the merge driver's side
+    ("Re-anchor after the merge is committed, or not at all"); this enforces it for the human
+    who types the command anyway.
+  - **Monotonicity**: the write happens only when the committed `baseRev` is an ancestor of
+    the newly resolved rev. Equal keys still take the existing "nothing to re-anchor" path.
+
+  Ancestry that cannot be established refuses too, rather than defaulting to either verdict:
+  `merge-base --is-ancestor` is read as three answers (`0` / `1` / anything else with a
+  `fatal:`), and a `1` from a **shallow** checkout is discarded as unusable — truncation makes
+  git report "not an ancestor" about commits that plainly are one. A `0` is trusted
+  everywhere, shallow included, because a truncated walk can only lose reachability, never
+  invent it.
+
+  `gen:schema` and every build are untouched: since #5358 they do not write this file at all,
+  so a build during a merge behaves exactly as before.
+
+- 1b49eaf: fix(objectql,spec): app-declared `capabilities` reach the registry with package provenance (#5870, #4967 Part 2)
+
+  An authorization capability a package DEFINES (`defineCapability` →
+  `stack.capabilities`, ADR-0066 D1) never acquired registry provenance, so a
+  declaration that did not repeat its owner by hand was **declared but never
+  enforced**.
+
+  **FROM.** `ObjectQL.registerApp()` decomposes a manifest's metadata arrays and
+  calls `SchemaRegistry.registerItem(type, item, 'name', packageId)` — the only
+  seam that runs `applyProtection(item, { packageId })` and stamps `_packageId` /
+  `_provenance`. The key list driving that decomposition (`metadataArrayKeys`,
+  present twice in `packages/objectql/src/engine.ts`: the manifest seam and the
+  nested-plugin seam) carried every other Security-Protocol collection —
+  `permissions`, `sharingRules`, `roles`, `profiles`, `policies` — but not
+  `capabilities`. The other path a stack's security metadata travels,
+  `AppPlugin` → `MetadataManager.registerInMemory`, stamps nothing by design. So
+  `readDeclared(ql, 'capability')` always returned `[]`, and
+  `bootstrapDeclaredCapabilities` — which resolves the owner as
+  `cap._packageId ?? cap.packageId` — could never satisfy the first half.
+
+  The consequence was a contract that lied in the direction that costs the most:
+  `CapabilityDeclarationSchema.packageId` documents itself as the ADR-0086 D3
+  _fallback_ used "when the registry has not stamped `_packageId`", and the field
+  is `.optional()`, but in practice it was **mandatory**. Omitting it produced one
+  boot `warn` and one authorization grant that silently never took effect —
+  permission sets have rows and materialize, capabilities did not.
+
+  **TO.** `capabilities` is registered through the same provenance seam as
+  `permissions`, at both `metadataArrayKeys` sites, and `capabilities` →
+  `capability` joins `PLURAL_TO_SINGULAR` in `@objectstack/spec` so the items land
+  under the singular type name the seeder reads back (the same mapping
+  `AppPlugin`'s security bridge already used). A capability declared by a package
+  — or by a package's nested plugin — now carries `_packageId` /
+  `_provenance: 'package'`, is listable via `registry.listItems('capability')`,
+  and is seeded into `sys_capability` with `managed_by:'package'` and a real
+  `package_id`.
+
+  **What authors should do.** Nothing is required and nothing breaks: an authored
+  `packageId` still parses and still wins where the registry has not stamped
+  (items registered outside a package context). It is now genuinely optional —
+  drop it and the platform supplies the owner. Where both are present the registry
+  stamp takes precedence, as the schema always said; the showcase's
+  `showcase.export_data` keeps its authored `packageId` and names the same id the
+  stack does, so the two agree.
+
+  This does not change what may be created at runtime: `capability` has no entry
+  in `DEFAULT_METADATA_TYPE_REGISTRY`, and the runtime-create gate reads that
+  registry, not the item store — its verdict for the type is the same before and
+  after.
+
+- b5bdf48: `check:docs` 不再以 `gen:schema` 开头 —— 一条名字叫 check 的脚本不该改工作区
+
+  `check:docs` 原本是 `pnpm gen:schema && tsx scripts/build-docs.ts --check`。前半截是**生成器**:
+  `json-schema.manifest.json` 与 `authorable-surface.json` 陈旧时它会把这两个 **tracked** 文件写掉。
+  于是跑一次「检查」就改了跑它的人的工作区,而且陈旧本身**从未被报告**。这正是 #4711 从 `--check`
+  里摘掉的缺陷,只是换了个入口(#4723)。
+
+  在 `check:generated` 里最难解释:`check:authorable-surface` 排在 `check:docs` 前面,且前者失败**不会**
+  中止后者。所以 manifest 陈旧时跑一次聚合门禁的结果是 —— 一份红色报告,配一个已经被悄悄修好的文件。
+
+  修法与 #4711 同形:**检查只检查,生成交给调用方。**
+
+  - `check:docs` = `tsx scripts/build-docs.ts --check`,不再生成任何东西。
+  - 调用方本来就在生成:CI 的 `check:authorable-surface` 步骤、`check:generated` 的门禁顺序、
+    `pnpm build`、`apps/docs` 的 build。它们跑的是 `build-schemas.ts --check`,该模式写 gitignored 的
+    `json-schema/`、拒绝碰任何 tracked 文件(#4711),正是这里唯一合格的「显式先跑一步」。
+  - 顺带省掉一次重复生成:`check:generated` 与 lint.yml 的 typecheck job 原本各跑两遍 ~1600 个 schema。
+    实测 `check:docs` 从 8.97s 降到 2.05s。
+
+  原来的第一步还**顺手保证了新鲜度**,所以这一半必须补上,否则只是把「改工作区」换成更糟的
+  「假绿」——对着编辑前生成的树报告「文档已同步」。因此:
+
+  - `build-docs.ts` 在**所有模式**下先断言 `packages/spec/json-schema/` 存在且不旧于 `src/`,否则红着退出
+    并给出 `gen:schema` 命令。写模式尤其要拒绝:陈旧树上的 `gen:docs` 不会失败,它会**写出**陈旧页面,
+    即 `readsDist` 那个坑挪一个产物(AGENTS.md 记着它的代价)。
+  - 新鲜度规则 `schemaTreeIsStale()` 与 `distIsStale()` 同住 `scripts/check-regen-pending.mjs`:同一个问题、
+    三个消费方(生成器、pre-commit 钩子、merge driver 的提示),两份拷贝会朝「拿没人重建过的树渲染出
+    一个自信页面」的方向漂移(#4675)。与 `distIsStale` 唯一的有意差别是排除 `.test.ts` —— 测试文件不是
+    `build-schemas.ts` 的输入,算进去会让每个纯测试 PR 都被要求跑一次没有意义的 `gen:schema`。
+  - `check:generated` 的 GATED 表把这条依赖**声明**出来(`readsSchemaTree`),reconciliation 在生产者缺失或
+    排在消费者后面时失败 —— 数组字面量的顺序是一条真实依赖,不该靠巧合表达。
+
+  对使用者的影响:**`check:docs` 不再自足**。先跑 `pnpm --filter @objectstack/spec build`
+  (AGENTS.md 里本来就因 `dist` 那条要求先跑),或让 `check:generated` 按顺序跑。忘了也不会得到错的结论 ——
+  `build-docs.ts` 会指名道姓地拒绝。
+
+- 947d4f9: fix(spec): an ADR-0087 rename resolves a shadowed alias by VALUE, instead of always leaving it behind (#4923)
+
+  Every ADR-0087 D2 conversion that renames a key (`renameKey` /
+  `renameConfigKey`, so `object` → `objectName`, `filters` → `filter`,
+  `flow` → `flowName`, the four `notify` aliases, `description` → `subtitle`,
+  the datasource driver-config aliases, …) used to do **nothing at all** when the
+  canonical key was already present. The retired spelling then stayed in the
+  converted metadata forever — the conversion had not finished converting.
+
+  That was invisible while flow-node config contracts were `.strip`: the dead key
+  was silently dropped at the execute-time parse and the node ran. Once #4001 批 9
+  made those contracts strict it stopped being invisible — a stored `subflow`
+  carrying `{ flowName, flow }` loads today and would be refused at execute time
+  as a guard failure (not routable through a `fault` edge).
+
+  **What changes.** A rename that meets both spellings now splits on whether the
+  two values actually disagree:
+
+  - **Same value** (structural equality, so two separately-authored
+    `{ status: 'stale' }` filters count as one declaration) → the alias carries
+    nothing the canonical key does not, so it is **deleted** and the conversion
+    emits its usual notice. Lossless hygiene, and it makes the transform
+    idempotent in both shape and notices.
+  - **Different values** → **both keys are kept** and no notice is emitted. Two
+    spellings holding two different values is genuine author ambiguity, and an
+    upgrade tool that silently picked the canonical one would be editing a
+    configuration the customer never agreed to. The surviving pair is what lets
+    the strict node-config gates refuse with a prescription that **names both
+    keys** and asks for a decision.
+
+  `notify`'s nested `source: { object, id }` lift follows the same rule: a part
+  that repeats its flat counterpart is redundant and `source` is dropped, while a
+  part that disagrees leaves the node **entirely** untouched so `source` reaches
+  the strict contract intact. (The `wait` node's loose-key lift is deliberately
+  NOT covered — it moves keys between two locations rather than resolving two
+  spellings of one slot.)
+
+  **What an author sees.** Metadata that named one slot twice with the same value
+  loses the retired spelling at load and gains one deprecation notice per removal
+  — the same notice a plain rename already emitted, so `objectstack validate`
+  output is unchanged in kind. Metadata that named one slot twice with _different_
+  values is unchanged by the conversion and is now refused by the strict
+  node-config contracts with a message naming both keys; the fix is to decide
+  which value is right, put it on the canonical key, and delete the alias. The
+  batch-9 prescriptions were reworded accordingly: they no longer say the
+  surviving twin is "dead" (true only under the old rule), because a key that now
+  reaches that parse holds a value the canonical key does not.
+
+- c142ced: docs(spec,skills): the docs and the `objectstack-api` skill catch up with the endpoint executor (#5238)
+
+  The executor landed (#5040 E1–E8) and the blanket refusal of a non-empty `apis:`
+  became five per-endpoint publish gates — but three prose surfaces still told the
+  reader the opposite. That is worse than stale: each one is an _instruction_ an
+  upgrading author (very often an AI maintainer with nothing but that text) would
+  follow away from a capability that now works.
+
+  **Two prescription texts in `packages/spec` — the shipped half of this change.**
+
+  - `App.apis`'s `retiredKey()` tombstone said the stack-level `defineStack({ apis })`
+    it redirects to "is ALSO not executable in v17 (#4936) … until the endpoint
+    executor ships". A tombstone that redirects somewhere has to be true about the
+    place it points at; this one sent the author to a surface it called dead in the
+    same sentence, so the natural next move was to keep serving the route from
+    handler code. It now says the surface EXECUTES from protocol 17, names the five
+    gates, and carries the two things to get right when moving a declaration up a
+    level: the `/api/v1/apps/<namespace>/<subpath>` carve-out with an explicit
+    `manifest.namespace` (ADR-0121 D1/D2), and `authRequired` defaulting to `true`
+    with ADR-0121 D6's armed-`rateLimit` pairing on an explicit `false`. The removal
+    half is untouched — `App.apis` was never read and is still gone — and #4936 is
+    still named, because the history is why the redirect exists at all.
+  - The `defineStack({ server })` module header said #5040 "wires endpoint-level
+    `rateLimit` — still unwired today". It is wired. The header now also states the
+    relationship an author of the server-level budget actually needs: endpoint
+    buckets are keyed in their own namespace, so the two budgets meter
+    independently rather than sharing a counter.
+
+  Both feed `content/docs/references/` through `gen:docs`; those two pages move with
+  them and nothing else does.
+
+  **Hand-written docs.** `protocol/kernel/http-protocol.mdx` traded its "that surface
+  has no executor" callout for a real **Declarative Endpoints** section: the serving
+  chain (match → policy chain → delegation to the same pipelines the built-in routes
+  use), the five gates, the policy answers (401 / 429 + `Retry-After` /
+  `Cache-Control: private, max-age=<ttl>` on successes only), and the identity that is
+  easy to get wrong — an unmatched path, and a **method mismatch on a declared path**,
+  both keep the transport's bare `404` byte for byte, because the seam is Hono's
+  `notFound` and not a registered route, so there is no method set to report a `405`
+  over. `getting-started/quick-reference.mdx` gains the compact lookup entry.
+
+  **The `objectstack-api` skill** stopped describing `ApiEndpointSchema` as a
+  four-arm `type` union with a `target` and gained a section that teaches the current
+  capability: when `apis:` beats `contributes.routes` (and when it does not — real
+  handler code), the carve-out, the gates as _things to run `objectstack validate`
+  for_ rather than texts to memorise, D6 with its `enabled === true` predicate spelled
+  out, and the mapping keys' minimal semantics (projection by dot path; no
+  `transform`; no `inputMapping` on a bodyless operation). It points at the
+  `declarative-apis-endpoints-live` upgrade entry rather than restating the review,
+  so there is one source of truth for it.
+
+  Every claim above was measured against the built spec rather than believed: the
+  doc example publishes, the `authRequired`-omitted shape resolves to `true`, and the
+  `rateLimit` written without `enabled: true` beside `authRequired: false` is refused
+  with its prescription. The tombstone's new text is pinned two-sided (it must say
+  the new thing AND must not say the retired one, with `#4936` still present) so a
+  regression cannot pass by emptying the message.
+
+- eda599e: fix(platform-objects): 超预算后台 seed 期间不再空库自证 —— 一次启动不再跑两套契约
+
+  #4769 已把 ADR-0104 的空库自证从 `kernel:ready` 挪到 `app:seeded`(本次启动自身数据的结算点),但保留 `kernel:ready` 作为「从不 seed 的内核」的兜底。剩下的窗口是这两个钩子**到达顺序可以颠倒**:`AppPlugin` 的 inline seed 超出软预算(`OS_INLINE_SEED_BUDGET_MS`,默认 8s)后转入后台,于是 `kernel:ready` 先到、兜底自证在 seed 仍在写的时候签发证书并把闸门翻到 strict——同一次 seed 运行的后半段撞上前半段从未见过的契约。showcase 冷启(`OS_INLINE_SEED_BUDGET_MS=1`)实测:自证发生在 +0.470s,seed 结算在 +3.617s,窗口 3.147s。
+
+  现在两个钩子都先问一句「本次启动自己的 seed 落定了吗」,任一处报告仍有未结算的 seed 源就不签发。`app:seeded` 同样受这道检查约束——多 config app 的 bundle 会每个 app 触发一次,第一次并不是本次启动的结算点。
+
+  新增 `seed-settlement` 契约(`@objectstack/spec/contracts`)承载这个信号,而不是让 platform-objects 去嗅 runtime 内部的 `seed-datasets` 服务:那个数组的存在只能说明「seed 源存在」,永远说明不了「已经落定」,而这两件事之间的差正是本 bug 的整个窗口。runtime 在选择分支之前先声明 seed 源,并在写入真正结束的同一刻结算它。
+
+  **multi-tenant 与 `skipSeedData` 的 ADR-0104 姿态(2026-08-06 裁定,#4795)**:这两种部署会注册 seed 数据但在启动时并不写入(前者按 org 在 `sys_organization` insert 时重放,后者是 `os migrate` 的只读规划启动,#3917),`app:seeded` 永不触发。它们的姿态是**启动时不自证,等 `os migrate … --apply` 在真实扫描的证据上落笔**——由同一个判据自然得出,不需要单独分支。这是答案而不是缺口:在启动那一刻断言一次尚未发生的 per-org 重放不含违规值,正是 #4769 的同一个错误、只是引信更长;而停在 warn-first 是可恢复的方向,随时可由 `os migrate value-shapes --apply` / `os migrate files-to-references --apply` 关闭。
+
+  `@objectstack/objectql` 侧只更新了 #4769 撤销机制的注释:「后台 seed 收尾晚于签发」不再是它要兜的场景(已在源头关闭),它对 `os dev` 热重载 seeder、运行期 marketplace 安装以及 lax 开关仍然有效。
+
+- 52760bf: fix(spec): a reference page's opening paragraph is the module's own doc block, never a symbol's (#5059)
+
+  `getFileDescription()` took the **first** doc block anywhere in a `*.zod.ts`
+  file, verbatim, and published it as the page's opening paragraph. That is not a
+  rule about descriptions — it is a rule about _ordering_: whichever declaration
+  happened to sit at the top of the file donated its comment to a public
+  document. Adding a helper above the first schema silently rewrote a published
+  page, and no gate could see it. `check:docs` compares the generated page against
+  the source and the page reproduced the wrong block faithfully, so there was no
+  drift to report; the trap was written down when the generator was built and
+  still landed on `main` twice.
+
+  The measured victim surface was **six pages**. The Translation protocol
+  reference opened with `Shared history sentence for every shape in this file
+(#4001).` — this repo's internal tightening-campaign narrative — and the Mapping
+  page with its sibling. Four more had no history constant anywhere near them:
+  `api/contract` published the doc of `ApiErrorSchema.code` (a comment _nested
+  inside_ an object literal), `api/realtime` published `Transport Protocol Enum`
+  on a page documenting fourteen schemas, and `api/protocol` / `kernel/plugin` the
+  same shape. Any future "move a helper to the top of the file" makes another.
+
+  The selection now follows **TSDoc's own rule, read back**: a doc block belongs
+  to the declaration it immediately precedes — which is exactly the text an editor
+  shows when you hover that symbol. So a module description must be a block that
+
+  - starts at column 0 (a block indented inside a declaration body documents a
+    property, never a module),
+  - appears before the first declaration (imports and re-exports introduce no
+    symbol of their own and do not close the header zone), and
+  - is not immediately followed by a declaration.
+
+  When no block qualifies the page prints no description at all — 宁可缺,不要错.
+  A confidently rendered internal note is a page that lies about its subject,
+  which is worse for a reader (and for an AI author working from these pages) than
+  a page that opens with its `Source:` pointer.
+
+  **Twenty reference pages lost an opening paragraph**, each of which was a
+  symbol's JSDoc rather than the module's: the six above plus `ai/solution-blueprint`,
+  `ai/tool`, `api/error-code-ledger`, `api/router`, `automation/approval`,
+  `cloud/template-manifest`, `data/driver-mysql`, `data/driver-postgres`,
+  `data/driver-sqlite`, `kernel/manifest`, `shared/enums`, `system/doc`,
+  `system/notification`, `ui/responsive`. **No page lost a real module header** —
+  the other 178 pages with a `Source:` line keep their description byte for byte.
+  A module that wants its opening paragraph back writes one block that documents
+  no symbol; 178 sources already do.
+
+  The rule is also the gate. The issue proposed failing on first sentences
+  matching `#\d{3,}` / `Shared history`, but that recognises only the
+  history-constant subclass, and only after publication — it would have caught two
+  of the six. A selection rule that cannot pick a symbol's comment makes the whole
+  class impossible instead. `scripts/lib/file-description.ts` (extracted from
+  `build-docs.ts`, following `format-type.ts` #4912 and `escape-mdx.ts` #5452) and
+  its pin suite `scripts/file-description.test.ts` carry it, corpus check included.
+
+- 5543020: fix(spec): docs-gen no longer cuts a nested `{…}` / `<…>` in half (#5452)
+
+  The reference-docs generator wraps a delimited fragment of `.describe()` prose
+  in an inline-code span so MDX renders it literally instead of parsing it as a
+  JS expression or a JSX tag. It located the fragment's closing delimiter with
+  `indexOf` — the **first** closer, not the **matching** one — so any nested pair
+  was wrapped only up to its inner closer and the outer one fell outside the
+  span.
+
+  The published symptom: `{{var}}` in a description was emitted as
+  `` `{{var}` `` followed by a stray `}`. Readers saw `{{var}` plus an orphan
+  brace on precisely the rows that teach template-variable syntax, where the
+  paired double brace _is_ the thing being documented. Nesting is not an exotic
+  input in this corpus — template interpolation and filter-map examples both
+  produce it.
+
+  The matcher now counts nesting depth, so the whole pair lands inside one code
+  span. Five rows across four regenerated reference pages change:
+
+  - `references/ai/model-registry.mdx` — `PromptTemplate.system` / `.user`,
+    both `{{var}}`
+  - `references/automation/flow.mdx` — `flow.nodes[].outputSchema`,
+    `{{nodeId.field}}`
+  - `references/ai/solution-blueprint.mdx` — the roll-up `filter` example,
+    `{ status: { $in: [...] } }`
+  - `references/api/analytics.mdx` — the retired `query` envelope,
+    `{ cube, query: {...} }`
+
+  The issue reported three; the last two were cut in the same place but start
+  with a single brace, so the `` `{{ `` grep that found the others could never
+  have seen them.
+
+  Unchanged: a single `{…}` pair, a `{<id>}` nest, and a lone unmatched `<` / `{`
+  (entity-escaped, e.g. a SemVer range `>=4.0 <5`) all escape exactly as before.
+  No package export or runtime behaviour changes — the fix is in
+  `scripts/build-docs.ts`, whose escaping moved to `scripts/lib/escape-mdx.ts` so
+  it can be pinned directly rather than by grepping emitted `.mdx`.
+
+- 880d343: fix(spec): the reference generator quotes a literal by its `typeof`, so numeric literals stop being written down as strings (#5729)
+
+  `formatType()`'s two literal branches wrapped every value in `'…'` without
+  looking at its type — `prop.enum.map(e => `'${e}'`)` and
+  `return `'${prop.const}'``— so a **numeric** literal union was printed as a
+**string** one.`FormSection.columns` is the specimen the issue was filed from:
+  it is declared
+
+  ```ts
+  z.union([
+    z.enum(["1", "2", "3", "4"]),
+    z.literal(1),
+    z.literal(2),
+    z.literal(3),
+    z.literal(4),
+  ]);
+  ```
+
+  and `content/docs/references/ui/view.mdx` rendered it as
+  `Enum<'1' | '2' | '3' | '4'> | '1' | '2' | '3' | '4'`, where the second half is
+  those four `z.literal(<number>)` variants. The two halves came out
+  indistinguishable, so the page claimed the key takes strings only — while the
+  schema accepts both `2` and `'2'`.
+
+  For these pages that is a contract error, not a typo. They are the authoritative
+  input for an AI author (ADR-0033), and a literal union is a copy-the-spelling
+  surface: whatever quoting the page shows is what gets written. #5611 paid for it
+  directly — its `RecordDetailsProps.sections[].columns` was meant to be a numeric
+  literal union, the generated reference said strings, and the PR abandoned the
+  shape for `z.number().int().min(1).max(4)` to escape the contradiction. The
+  generator was defining the contract backwards.
+
+  Quoting is now decided per **value**, not per node, because JSON Schema states
+  member types per value and an `enum` may mix them (`z.nativeEnum({ A: 1 })`
+  emits a numeric `enum`): strings stay quoted, `number`/`boolean` render bare,
+  and `null` renders as the keyword.
+
+  Eight reference pages change, 11 lines, and in one direction only — quotes are
+  removed from 18 non-string literals and no string literal loses its:
+  `api/dispatcher`, `api/errors` (`success: false`), `data/data-engine`
+  (`sort: Record< string, 1 | -1 >`), `data/driver-nosql` (`projection:
+Record< string, 0 | 1 >`), `data/object` (`systemFields` / `stageField: false`),
+  `security/explain` (`version: 1`), `ui/dashboard` (`filterBindings`) and
+  `ui/view` (`columns: … | 1 | 2 | 3 | 4`). Every `Enum<'a' | 'b'>` on those
+  pages is untouched.
+
+- 6e82972: fix(spec): the reference generator prints a `retiredKey()` tombstone as `never`, not `any` (#5606)
+
+  `retiredKey()` is `z.never()`, which `z.toJSONSchema` emits as `{ "not": {} }` —
+  a node with no `type`, no `$ref` and no `enum`. `formatType()` had no branch for
+  it, so every one of the ~28 tombstones in the spec fell through to the
+  `prop.type || 'any'` tail and the generated reference pages typed a **removed**
+  key as **`any`**.
+
+  That is the worst available rendering for a retirement. These pages are the
+  primary input for an upgrading author — very often an AI one (ADR-0033) — and
+  `heading?: any` does not read "this key was deleted", it reads "this slot exists
+  and nothing validates it": strictly _more_ inviting than the `heading?: string`
+  it replaced. The author writes it, the parse rejects it with the `[REMOVED]`
+  prescription, and the prescription arrives only after a wrong metadata file
+  already exists.
+
+  Two changes, both in `scripts/lib/format-type.ts`:
+
+  - **`{ not: {} }` now renders as `never`.** Accurate TypeScript — the key's
+    `z.input` type _is_ `never` — and, unlike `any`, self-evident with no prose
+    to lean on.
+  - **Tombstones are dropped from an inline shape summary before
+    `INLINE_KEY_LIMIT` counts.** A summary cell prints `k?: type` for the first
+    four declared keys and has no description column, so a nested tombstone had
+    nowhere to put its prescription at all: `ui/theme.mdx` advertised
+    `{ base?: string; heading?: any; mono?: any }` with both prescriptions
+    appearing NOWHERE on the page. Retired keys are no longer authorable surface,
+    so they no longer spend one of the four slots — nor push a key the author
+    must write behind the `…`. The known workaround of moving a tombstone to the
+    bottom of the shape cannot cover this: #5248 retired `IndexSchema` down to
+    three live keys, and with a limit of four the first tombstone is then
+    _mathematically_ guaranteed into the summary.
+
+  Per-key table rows are unaffected and keep carrying the full `[REMOVED]`
+  prescription in their description column; their type cell simply now says
+  `never` instead of `any`.
+
+- 4615a18: fix(spec): the reference docs index is keyed by `<category>/<name>`, so a schema is documented on the page of the file that exports it (#4696)
+
+  `build-docs.ts` kept two maps — schema name to category, schema name to page —
+  keyed by the **bare** schema name, globally. A bare name is not a schema
+  identity: `build-schemas.ts` publishes `json-schema/<category>/<Name>.json`, so
+  the same name under two categories is two published schemas. The docs index now
+  uses that same `<category>/<name>` key.
+
+  Two things were wrong under the old key, and the second one turned out to be
+  the bigger of the two:
+
+  - **Same name, two categories, last writer wins.** `ServiceStatus` is an enum
+    declared in `api/discovery.zod.ts` and an object declared in
+    `system/core-services.zod.ts`. `system` was walked later, so the API enum was
+    written to `content/docs/references/api/core-services.mdx` — a page with no
+    `packages/spec/src/api/core-services.zod.ts` behind it.
+  - **A re-export was invisible.** The scan matched `export const X` only, so a
+    name reaching an entry point through `export { XSchema } from '…'` — or a
+    bare `export { XSchema }` of an imported binding — had no entry for its own
+    category at all, and fell through to the case above. That accounts for 25 of
+    the 26 misplaced schemas, not name collisions: `RetryPolicy` under
+    `./automation` and `./system`, the five `ConnectorInstance*Auth` under
+    `./integration`, `HttpMethod` / `HttpRequest` under `./api` and `./ui`, the
+    twelve package-registry RPC envelopes under `./api`, and the metadata-loader
+    pair under `./system`.
+
+  The index now records every **value** export a `.zod.ts` names — declarations
+  and re-exports alike, type-only exports excluded because they publish no
+  `z.ZodType` — and a declaration owns the page over any number of re-exports of
+  it. Nine pages that named no real file are gone; their sections moved onto the
+  page of the file that genuinely exports them, which is also the page whose
+  `Source:` line and `import … from '@objectstack/spec/<category>'` example were
+  already true:
+
+  | removed page                 | sections now live on          |
+  | :--------------------------- | :---------------------------- |
+  | `api/core-services`          | `api/discovery`               |
+  | `api/http`                   | `api/router`                  |
+  | `api/package-registry`       | `api/protocol`                |
+  | `automation/retry-policy`    | `automation/control-flow`     |
+  | `integration/connector-auth` | `integration/connector`       |
+  | `system/metadata-loader`     | `system/metadata-persistence` |
+  | `system/metadata-types`      | `system/metadata-persistence` |
+  | `system/retry-policy`        | `system/job`                  |
+  | `ui/http`                    | `ui/view`                     |
+
+  Cross-reference links follow the same key: a `$ref` links to the page in the
+  reader's **own** category when that entry point exports the name, and otherwise
+  to the single declaring category. When two categories declare the name, no link
+  is emitted at all — plain text beats a confident link to the wrong schema.
+
+  A name that two files inside one category both claim is now a **build error**
+  naming both files, never an overwrite.
+
+- 7f62706: ADR-0087 semantic-migration ledger: register the immediate retirement of the `ctx.user.roles` alias
+
+  The `roles` alias on `ActorUser` — the `user` envelope an action body reads as `ctx.user` and an
+  AI route handler reads as `req.user` — was removed outright in protocol 17 (#6011, runtime half in
+  PR #6048): no deprecation window, no dual-emit. The retirement had shipped, but the ADR-0087
+  migration ledger carried no entry for it, so it was invisible to `objectstack migrate meta`,
+  `spec-changes.json` and the generated upgrade guide — while all three sibling faces of the same
+  ADR-0090 rename (`data.hookContext.session.roles`, `ui.actionSession.roles`,
+  `CEL/formula: current_user.roles`) were registered. This adds the missing entry
+  (`actor-user-roles-to-positions`) and regenerates the artifacts projected from it.
+
+  FROM `ctx.user.roles` / `req.user.roles` → TO `ctx.user.positions` / `req.user.positions`. The
+  value is unchanged: both keys were filled from one assignment (`roles: core.positions`), so this is
+  a pure key rename. Fix: rewrite the read. `roles.includes('admin')` used as an ACCESS CHECK is not
+  renamed to `positions.includes('admin')` — ask the security service instead (ADR-0095); renaming
+  that read migrates the defect rather than the code.
+
+  Note this face has **no window**, unlike its neighbour `ctx.session.roles` (#5613), which still
+  dual-emits for one release. `ctx.user.roles` is already absent in 17: a typed body fails `tsc` at
+  the read, an untyped or sandboxed one silently sees `undefined` — so move the read as you upgrade,
+  not after. `ctx.user` has never had a spec schema (it is a runtime TS interface), so no
+  `retiredKey()` tombstone can carry the prescription; this ledger entry and the generated upgrade
+  guide are the channel.
+
+  Spec source change is the registry entry only — no schema, no export, and no authorable key moved.
+
+- 1eb13a0: **`ApiEndpointSchema.path` 的 `.describe()` 换成 carve-out 形状的示例(#5310)**
+
+  这段文案过去是 `URL Path (e.g. /api/v1/customers)`。ADR-0121 D1 把声明路径收紧为
+  `运行前缀 + /apps/ + 命名空间 + 子路径`(`appEndpointMountPrefix()` =
+  `/api/v1/apps/<namespace>/`),publish 门 `namespaceGate` 对 carve-out 之外的路径直接拒绝
+  —— 也就是说,**词表自己举的例子,publish 会当场拒**。
+
+  **为什么现在要紧。** #5271 之前 `api` 没有注册 schema,`/meta/types` 不为它出 JSON Schema,
+  Studio 只能给一个 raw-JSON 文本框,这段 `.describe()` 没有渲染面。#5271 之后它成为
+  metadata-admin 端点表单里 `path` 字段的说明文字,并进入生成的 JSON Schema —— 于是一段会被
+  拒绝的示例,变成了作者(按 ADR-0033,常常是 AI 作者)照抄的第一手提示。
+
+  **新文案**给出 carve-out 形状 `/api/v1/apps/<manifest.namespace>/<subpath>`、一个具体示例
+  `/api/v1/apps/crm/leads`,并说明命名空间段派生自 `manifest.namespace`(ADR-0121 D2)而不是
+  作者的自由字段。措辞直接复用 `endpoint-publish-gate.ts` 里 `namespaceGate` 的拒绝文案,
+  没有新发明判据 —— 作者在表单里读到的,和被拒时读到的,是同一条规则。
+
+  **只改了文案。** schema 结构、`/^\//` 正则、门逻辑一律未动:`path` 仍是一个以斜杠开头的
+  字符串,carve-out 仍然只由 publish 门(和运行期匹配器)判定。因此这不是破坏性变更,今天能
+  发布的声明明天照样能发布。
+
+  `ApiMappingSchema` 的三条 `.describe()` 逐条复核后**保持原样**:`source` / `target`
+  (_Source field/path_ / _Target field/path_)不举例,也没有说错;`transform`
+  (_Transformation function name_)描述的键确实会被门整键拒绝,但那属于「词表冻结后,被拒键
+  是否应在表单里自陈」的另一类问题,已另行归档,不在本次文案修正内。
+
+  配套:`packages/spec/src/api/apis-publish-gates.test.ts` 新增一条断言,把 `.describe()` 的
+  文本**读回来**再喂给门 —— 文案里出现的每个具体示例路径都必须在它自己命名的命名空间下通过
+  `validateApiEndpointDeclarations`。把一个会被拒的路径写回 `.describe()`,这条测试就红。
+
+- 244ca86: fix(spec): 参考页给「元素是联合类型」的数组补上括号 —— `(string | number)[]`,不再是 `string | number[]` (#5338)
+
+  参考页类型单元格由 `packages/spec/scripts/lib/format-type.ts` 渲染,数组分支此前直接把
+  `[]` 拼在元素渲染结果之后。TypeScript 里 `[]` 的结合优先级高于 `|`,所以
+  `string | number[]` 表达的是「一个 string,**或者**一个 number 数组」,而 schema 说的是
+  「一个数组,元素是 string 或 number」—— **单元格印出的类型和 schema 声明的不是同一个**。
+  参考页的类型单元格正是元数据作者(尤其是 AI 作者)直接照抄的那一行:照着
+  `string | number[]` 写下一个裸 string,schema 会当场拒绝,而页面看起来是允许的。
+
+  修法只有一处:#4912 为交叉类型引入的深度扫描 `hasTopLevelIntersection` 放宽成
+  `hasTopLevelUnionOrIntersection`,同时识别顶层 `&` 与 `|`。两者本来就是同一条规则——
+  `[]` 对这两个运算符都不分配律(`A & B[]` 是 `A & (B[])`,`A | B[]` 是 `A | (B[])`)——
+  所以合用一次扫描。深度扫描原本就正确忽略 `{}` / `< >` / `[]` / `()` 内部的运算符,
+  因此 `Enum<'a' | 'b'>[]`、`Record<string, string | number>[]`、`{ k?: string | number }[]`
+  以及 markdown 链接都保持原样,不会多出括号。
+
+  重新生成 `content/docs/references/**` 后共 19 个参考页、42 行单元格得到修正
+  (47 处补括号),没有新增页,也没有页面被复活;`check:docs` 报告 240 个生成文件全部同步。
+
+  #4912 的交叉类型侧行为不变:`({ label: string; value: … } & Record<string, any>)[]`
+  仍然带括号,该 PR 的全部 pin 用例保持绿。
+
+- 0b51bb6: fix(spec): 参考页不再把「已声明键 + passthrough」的对象塌缩成 `Record` (#4912)
+
+  `gen:docs` 的类型渲染器先判 `additionalProperties`、后判 `properties`,而 JSON Schema 把
+  `.passthrough()` / `.catchall()` 对象**同时**表达为这两者 —— 于是每个「有形状、又开放」的
+  对象在参考页上都被渲染成一个光秃秃的 `Record< string, any >`,**已声明的键被整个抹掉**。
+  `BulkActionParam.options` 是立案时的样本:它的 `label` / `value` 是**必填**的,页面却显示
+  「无形状」。PR #4909 当时是在该键的 `.describe()` 散文里手工补偿的,那是逐点补偿,不是修复。
+
+  声明键与开放性是**两个独立的事实**,现在分别呈现:
+
+  - 之前:`Record< string, any >[]`
+  - 之后:`({ label: string; value: string | number | boolean } & Record< string, any >)[]`
+
+  数组元素上的括号是必需的 —— `A & B[]` 在 TypeScript 里是 `A & (B[])`,不加括号等于声明了
+  另一种类型。已声明键超过四个时仍然省略,`…`(还有更多**已声明**键)与
+  `& Record< string, any >`(还接受**未声明**键)是两件不同的事,单元格两者都印。
+
+  本次重生成影响 6 张参考页共 12 个单元格,全部是恢复被抹掉的声明键,没有任何一页丢失形状:
+  `ui/bulk-action`(`params`、`options`)、`ui/view`(`gantt`、`tree`,ListView 与
+  ObjectListView 各一份)、`ui/dashboard`(widget `options`)、`api/protocol`(三处 AI
+  `messages`)、`system/auth-config`(`socialProviders`)、`kernel/startup-orchestrator`
+  (`plugin`)。
+
+  渲染逻辑从 `build-docs.ts` 抽到 `scripts/lib/format-type.ts` 并配了单测:此前要断言它的输出
+  只能跑完整个生成器再 grep `.mdx`,这正是该塌缩能在整个 #4001 战役期间无人察觉的原因。
+
+- d9971d3: fix(driver-sql): `$field` 跨字段比较改为按 ADR-0112 响亮拒绝,不再抛裸 TypeError
+
+  `{ amount: { $gt: { $field: 'budget' } } }`(spec `FieldReferenceSchema`,由 `compileCelToFilter` 在转译含字段间比较的 CEL 权限/RLS 规则时产出)此前被 SqlDriver 当作**绑定值**交给驱动,sqlite 抛出无 `code`、无 `status` 的裸 `TypeError` —— 落在 `INVALID_FILTER` 信封之外,到客户端表现为不透明的服务端错误。更隐蔽的是列表位置:`$in` / `$between` 里的 `$field` 成员连报错都没有,直接静默返回零行。
+
+  现在两者都以完整信封拒绝(`error.code = INVALID_FILTER`、HTTP 400、无 `[sql-driver]` 前缀),报错点名字段、运算符与被引用字段,并说明跨字段比较**当前仅内存求值路径(`matchesFilter`)支持**。三个比较发射点统一处理,Filter Protocol 与数组三元组两种写法得到同一答案。
+
+  同一处闸门补上了 issue 指出的通用臂:**已知运算符 + 无法绑定的值形态**(标量比较位上的普通对象 / 数组)此前同样是裸 `TypeError`,现在也返回 `INVALID_FILTER`。`$in` / `$nin` / `$between` 的正常数组绑定不受影响。
+
+  `FieldReferenceSchema` 声明保留,JSDoc 补注执行支持面(内存求值 ✅ / SQL 下推 ❌ 响亮拒绝);SQL 列对列编译实现见 #5222。
+
+- 502564d: fix(spec): `check:liveness` 的 stale-evidence 从 `⚠` 升级为 `✗` 判红,摘要行不再把「声明数」当作「解析成功数」(#5623)
+
+  `live` 判定的语义就是它的 evidence 指针 ——「这个属性有运行时消费者,在这里」。指针指向本仓已不存在的文件时,这条声明就不再可证伪:declared 有,enforced 无。而把它变成这样,只需要一次目录重组或一次改名。
+
+  实测(`origin/main`,把 `packages/spec/liveness/query.json` 的 5 条 evidence 路径指回迁移前的 `packages/plugins/driver-sql/...`):
+
+  ```
+  evidence paths: 330 resolved against this checkout, 101 attributed to another repo (…)
+
+  ⚠ 5 'live' entr(ies) cite a missing file:
+      query/fields → packages/plugins/driver-sql/src/sql-driver.ts
+      …
+  ```
+
+  退出码 **0**。五条断链逐条点名了,CI 一路绿灯 —— 而且摘要行里的 `330` 一动没动,因为它数的是 local 路径**总数**,不是解析成功数,"resolved" 这个词是失真的。
+
+  **为什么以前是 `⚠`,以及为什么现在不该是。** 这不是对本仓路径的有意宽容,是解析器时代的遗留:#3857 之前的检查取 `evidence.split(':')[0]` 当文件名,227 条里报 48 条、**全是误报**,那种情况下它当然不能判红。`evidence.mts` 修好了解析(realm marker 归属 + 仓根路径提取),此后这份清单一直是空的 —— 恰恰是这一点让「有命中」重新变成信号。当时被那 48 条噪声埋掉的唯一一条真腐烂(`object.enable.clone`,消费者从 `@objectstack/objectql` 搬到了 `@objectstack/metadata-protocol`),就是宽容的实际代价。
+
+  同族的旁证:同一目录下的 `check-empty-state.mts` 对 `rotted-evidence` 一直是 `✗` + exit 1,README 也写着它的执行点路径「resolves like `evidence` above, so a pointer that rots is reported rather than trusted」。真正有意的宽容在这个 gate 里都写明了理由(`verifiedAt` 的年龄、undrilled 容器计数、`PENDING_GOVERNANCE` —— 每一条都在代码里明说 "never fails CI"),stale-evidence 那一段一个字都没有。
+
+  **改动**
+
+  1. **`live` 条目引用本仓缺失文件 → `✗` 判红**,并给出三条修法(仓内搬家就改指针并补 `verifiedAt`;搬去别的仓就加 realm marker;消费者真没了就按 ADR-0049 重新判定,而不是随手指向一个看着像的幸存者)。
+     **边界不变**:cross-repo attribution(`objectui:` / `cloud:` / `packages/services/service-ai/…`,当前 101 条)只计数、不解析,永远不判红 —— `checkEvidence` 只对 local 桶做存在性检查,这个分界是结构性的,不是靠约定。
+  2. **摘要行改成两个数**,而不是二选一:
+     ```
+     evidence paths: 330 repo-local path(s) declared by 'live' entries, 330 resolved against this checkout; 101 attributed to another repo (…)
+     ```
+     两个数都留着是有原因的:"declared" 是 #3857 留下的解析健康度信号(有单测防止解析器退化成「什么都提不出来」而假绿),"resolved" 是判定。绿的时候两者相等 —— 这正是当初只印前一个会被读成通过的原因。有断链时行尾追加 `, N MISSING`。
+  3. 新增 `--ledger-root=<dir>`:让 gate 读 `packages/spec/liveness` 的一份副本。自测据此把真 gate 跑在「只坏了一条指针」的 ledger 副本上,不改动仓库里任何文件。
+
+  `check-liveness.test.ts`(新增 8 例)直接 spawn 真脚本断言退出码 —— 这个 bug 从来不是「检查看不见」:它把五条全点名了还是 exit 0,所以只测 `checkEvidence` 的单测全程是绿的。
+
+  脚本本身(`scripts/`)不进 npm 包,但 `packages/spec/liveness/**` **是发布内容**(`package.json` 的 `files` 里有 `liveness`,`npm pack --dry-run` 实测 29 个文件入包,含该目录的 `README.md`)。一个新开始判红的 gate 必须同步它面向作者的文档,否则下一位作者只能靠撞红的 CI 才知道规则变了 —— 所以 README 里那段新的失败语义也随包发出,按 patch 记账,而不是空 frontmatter(空 changeset 是 `changesets/action` 的真实输入,全空集合会静默绿着卡住发布 —— #4898 卡住 17.0.0-rc.2 的就是这个)。当前 `main` 上 330 条本仓路径全部解析成功,该 gate 落地即绿。
+
+- 471839d: fix(spec): classify the 22 dashboard widget keys and refuse undeclared container inheritance (#4956)
+
+  The spec liveness ledger's `dashboard.widgets` entry carried one blanket `live`
+  verdict plus a `note` asserting that the per-widget props were _"classified in
+  the DashboardWidgetSchema subtree"_. **No such subtree ever existed.** The gate's
+  walk drills one level and only through an explicit `children`, and `widgets`
+  declared none — so all 22 authorable keys of the strict `DashboardWidgetSchema`
+  were never classified, never counted as unclassified, and every run printed
+  "all governed-type properties are classified" anyway.
+
+  That gap — not evidence — is what carried `widgets[].responsive` through the
+  #3896 inert-key sweep that removed both its sibling `widgets[].performance` and
+  its literal namesake `view.responsive`. `view` is drilled through `children`, so
+  `list.responsive` got asked and went out; `widgets` was never asked. It was
+  finally retired in #4876 / PR #4995, by hand, four days late.
+
+  **What changed for authors**
+
+  The `objectstack build` / `objectstack lint` advisory now covers dashboards, so
+  five widget keys warn at build time (they never did before — `dashboard` was not
+  in the lint's type collections, because until now its ledger warned on nothing):
+
+  | Widget key               | Why it warns                                                                                                                   | What to do instead                                                                                               |
+  | :----------------------- | :----------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------- |
+  | `widgets[].colorVariant` | no render path reads the top-level key — only the authoring panels do                                                          | move it under `options` (the inline metric card reads it there); the dataset-bound path has no colour affordance |
+  | `widgets[].actionUrl`    | no renderer draws a per-widget action button; every `actionUrl` the dashboard renderer reads belongs to `header.actions[]`     | use `dashboard.header.actions[]`                                                                                 |
+  | `widgets[].actionType`   | pairs with the above                                                                                                           | as above                                                                                                         |
+  | `widgets[].actionIcon`   | zero readers in either repo                                                                                                    | as above                                                                                                         |
+  | `widgets[].aria`         | declared ARIA attributes never reach the DOM — the same false-compliance shape as the dashboard-level `aria` removed in 17.0.0 | delete it; the renderer emits its own `aria-*`                                                                   |
+
+  Advisory only — the build never fails on these. **Nothing is removed and no
+  runtime behaviour changes**: this records verdicts, it does not act on them.
+  Enforce-or-remove (ADR-0049) for the five is tracked separately.
+
+  Two verdicts worth knowing because they cut the other way: `requiresService` is
+  **live** — it reads as inert in the renderer repo but the REST layer strips
+  widgets whose service is unregistered (ADR-0057 D10) — and `compareTo` is live
+  on the inline chart path only; on the ADR-0021 dataset path the string arms are
+  dropped and `{ offset }` fails in the analytics executor.
+
+  **What changed for the gate**
+
+  `pnpm --filter @objectstack/spec check:liveness` gains a third direction. A
+  ledger entry sitting on a container property must now declare one of exactly
+  three dispositions, all of them data: **drilled** (`children`), **deferred** (a
+  `{ container, to }` row naming the coordinate that does classify the subtree),
+  or **recorded** (a row in the shrink-only
+  `scripts/liveness/undrilled-containers.baseline.json`). A container in none of
+  the three fails, and so does a baseline row whose container has since been
+  drilled.
+
+  A deferral is **resolved, not believed** — the target must exist (a governed
+  type root, or a drilled `type/prop` coordinate) and classify exactly the
+  container's child keys; a dangling or drifted target fails. That is the #4956
+  claim itself, made checkable: pointing a deferral at `DashboardWidgetSchema`
+  now produces a build failure naming it, where the same words in a `note` were
+  believed for a release.
+
+  Every run reports both populations (today: 58 containers / 292 child keys
+  classified nowhere, plus 6 resolved deferrals covering 248), `--undrilled`
+  prints the worklist, and the success line no longer claims a completeness it
+  does not have.
+
+- b508244: automation: `ActionDescriptor.resumeAuthority` no longer defaults to `'any'` — an
+  omission is now a distinct, reportable fact (#5561, from #3823)
+
+  The #3801 resume gate keys on the suspended node, so it covers a pausing node type
+  exactly when that type's author declared who may resume it. The schema default made
+  that impossible to check: Zod filled the key inside `defineActionDescriptor`, so
+  "the author chose `'any'`" and "the author never considered it" produced
+  byte-identical descriptors. #3823 is what the erasure cost — ADR-0044 pointed an
+  approval's revise edge at a generic `wait`, `wait` is legitimately `'any'`, and the
+  pause standing in a service-owned position inherited a fail-open value nobody chose.
+
+  The field is now optional with no default, and absent means absent. Two seams read
+  it: `AutomationEngine.registerNodeExecutor` warns once per node type when a
+  `supportsPause` descriptor omits it, and the new `check:resume-authority-declared`
+  gate fails CI on an omission in this repo's own executors.
+
+  **Not a behaviour change.** The engine already resolved the value with `?? 'any'`,
+  so an undeclared pausing type is still raw-resumable exactly as before — loudly now
+  instead of silently. Nothing needs migrating: an executor that declared
+  `resumeAuthority` keeps its value, and one that omitted it keeps today's semantics
+  and gains a warning telling it to state its intent. Making omission mean
+  _fail-closed_ is a breaking change still tracked on #5561 for a version window that
+  allows it; it is now a one-expression change rather than a schema migration.
+
+- 594508e: fix(spec): manifest 删行不再是纪律 —— 整 schema 消失必须相对 merge-base 自证 (#4725)
+
+  #4650 堵住了 `authorable-surface.json` 的手编删行捷径:被删的基线行现在必须在门禁
+  内自证。但它把「整 def 消失」这条路交给了 `json-schema.manifest.json` 的 #2978
+  ratchet —— 检查 (c) 的第 3 条出口至今原话写着「whole-schema removals are
+  adjudicated by json-schema.manifest.json」。**那个 ratchet 什么也没裁判。** 它的
+  `missing` 集合是「manifest − 本次产出」,而 manifest 是**同一个 commit 里可以随手
+  改的文件**:把导出、manifest 行、基线行一起删掉,`missing` 恒空,检查 (c) 又以
+  「def 已不再产出」为由放行它名下的每一行,`check:api-surface` 只是新鲜度门(重新
+  生成即绿)。三个门,一句话都不说 —— 和 #4650 修复前的形状同构,只是上移了一层。
+
+  实测(修复前,在测试沙箱里跑真源码):删掉 `src/data/index.ts` 里 **一行**
+  `export * from './validation.zod';` —— `ObjectSchema` 是直接从 `./validation.zod`
+  导入 `ValidationRuleSchema` 的,所以这 7 个 def 依旧从 `object` 元数据根**可达**、
+  它们的 116 个 key 依旧被作者书写、依旧被解析 —— `gen:schema` 与
+  `check:authorable-surface` **双双 exit 0**,消失的只是它们的 JSON Schema、
+  manifest 行,以及 ratchet 对它们的全部记录。
+
+  现在按 #4650 的同一结构重新锚定:
+
+  - **新增门禁「manifest deletion gate」**(`scripts/build-schemas.ts`):相对
+    **merge-base(HEAD, origin/main) 的 manifest** —— 本次 commit 改不动的那一份 ——
+    计算「离开已发布集合」的 def,每一个都必须有登记,否则红。它跑在检查 (c) **之前**,
+    所以 (c) 那句「交给 manifest 裁判」从此指向一个真的会出裁决的地方。
+  - **新增导出 `RETIRED_DEFS_BY_MAJOR`**(`@objectstack/spec`,
+    `src/migrations/registry.ts`):`RETIRED_KEYS_BY_MAJOR` 的上一层同胞,值是确切的
+    `` `${category}/${SchemaName}` `` —— manifest 里怎么写就怎么写。沿用 #4659 的
+    精确集合判定:不取叶名、不按前缀、不从相邻条目辐射。门禁失败时直接打印要粘贴的
+    那几行和它们该进哪个 major。
+  - **镜像检查**:表里登记了一个本次构建**仍在发布**的 def —— 一次没有任何东西消费的
+    登记 —— 直接失败,否则真正的删除可以在几个月后的别人的 PR 里落地,而门禁早已被
+    满足、当时没有任何人写下任何东西。
+  - 改名不是退休:`RENAMED_DEFS`(`scripts/lib/renamed-defs.ts`)在这张表之前被查,
+    一次改名不需要、也不允许写进这里 —— 那是在谎称契约收缩了。
+
+  **为什么是「声明」而不是「可达性」。** issue 建议复用 #4650 的可达性 BFS(「该 def
+  从元数据根不可达」)。这条在本层用不了,而且是**静默地**用不了:`reachableVia()` 从
+  `zodByDefKey` 取实例,而那张表只装**本次构建产出**的 def —— 一个刚刚不再产出的 def
+  必然答 `null`,也就是「不可达 ⇒ 放行」,正对着这道门要拦的那一类删除。加宽 BFS 也救
+  不了:def 已经从源码里没了,没有图可以走。所以本层唯一诚实的证据是声明,沿用 #5902
+  为 key 层定下的先例。
+
+  **离线沿用 #5235 的既有姿态,不新造第三种**:镜像检查不需要 git,任何环境都跑;
+  比较本身在解析不到 origin/main 时打印说明并跳过 —— 那些环境是已合并的不可变树
+  (镜像构建阶段、离网、fork、历史 tag 重放),「这个 PR 相对 main 删了什么」在那里
+  不是一个存在的问题,跳过不会让任何构建失败,因此不需要为它再加一个 in-tree 锚点。
+
+  `json-schema.manifest.json` 自己的描述同时更新了(并纳入陈旧判定,不会再漂移):
+  它此前写的「remove a key ONLY for a deliberate retirement」正是 issue 引用的那句
+  「唯一的要求,且没有任何机器校验」;现在它指向这道门和这张表。
+
+- 1c625ca: metadata: `getDiagnosed` — a metadata read that FAILED stops arriving as "nobody declared this"
+
+  `MetadataManager.loadDiagnosed` computes the ADR-0110 D3 verdict (a MISS and an OUTAGE
+  are different facts with opposite security meanings) and `get()` discarded it two hops
+  later: `load()` kept only `.data`, `get()` turned that `null` into `undefined`. Every
+  consumer of `get()` therefore received one `undefined` for two opposite facts and could
+  not have told them apart even if it had wanted to.
+
+  **New read.** `MetadataManager.getDiagnosed(type, name)` returns
+  `{ data, degraded, errors }` — the registry-first counterpart of `loadDiagnosed`, declared
+  as an optional member of `IMetadataService`. A registry hit is never degraded (it
+  consulted no loader); a clean miss is never degraded (every loader answered).
+
+  **`get()` is unchanged — zero breaking.** Same signature, same answer, same behaviour for
+  every existing caller, including the microtask-level ordering `register()`'s watchers
+  depend on. Only callers that ASK for the verdict pay for it. Making `get()` throw on
+  `degraded` was deliberately not done: the boot path degrades on purpose.
+
+  **Consumers switched**, each with a disposition argued for its own context rather than one
+  blanket rule:
+
+  - `getMetaItem` / `getMetaItemCached` — a degraded MetadataService read with nothing in
+    the registry now raises `503 SERVICE_UNAVAILABLE` instead of falling through to
+    `404 RESOURCE_NOT_FOUND`. This is the half that made the existing `#5532` comment ("
+    reaching here now means a real miss") untrue.
+  - `getMetaItemLayered` — the `code` layer joins the rule its `overlay` layer already
+    followed. `code: null` is a positive claim, and `lockSource = code ?? overlay ?? {}`
+    derives from it, so an outage could render an item the packager locked
+    (`_lock: 'full'`) as `editable: true, deletable: true`.
+  - `ObjectQLPlugin`'s `object` metadata-event refresh — logs `warn` naming the consequence
+    (the registry keeps the previous definition; nothing retries) and the fix, instead of
+    `debug` "metadata service has no fresh body". `warn` and not `error` because the write
+    already landed; only a re-read failed.
+
+  Hosts whose `metadata` slot is a shim that predates `getDiagnosed` are read as
+  "not degraded" — exactly what they could express before — so their behaviour is unchanged.
+
+- 71f205d: fix(driver-mongodb): 空 `$and` / `$or` / `$not` 按布尔单位元归约,非 filter 节点先响亮拒收 (#5239)
+
+  `translateFilter` 过去把组合子数组**原样透传**给 MongoDB。而 MongoDB 对空数组既不答
+  TRUE 也不答 FALSE,是第三种行为:**直接拒绝整条查询**(`$and/$or/$nor must be a
+nonempty array`)。于是 `{ $and: [] }` 与 `{ $or: [] }` 一路走到 `find` /
+  `countDocuments` / `updateMany` / `deleteMany`,变成一个不带 ADR-0112 错误码的服务端
+  异常 —— 而 `driver-sql`(#5134 / PR #5243)、`driver-memory`、`formula` 三家早已按单位
+  元作答。
+
+  改成与它们同一套**结构性三值归约**:先把整棵 filter 树判成 `true` / `false` /
+  `clause`,再据此产出。空 `$and` 归约为 TRUE(不产出条件),空 `$or` 归约为 FALSE 并产出
+  一个**真实的零行条件** `{ _id: { $in: [] } }` —— 关键在于「什么都不产出」等于 `{}`,而
+  `find` / `updateMany` / `deleteMany` 把 `{}` 读作**全部文档**,方向正好相反。`{}` 作为
+  `$or` 的分支仍是 TRUE 析取项,`{ $not: {} }` 仍是零行,这两条 MongoDB 本来就与布尔代数
+  一致,所以归约按结构做而不是只判 `length === 0`。发出的每个 `$and` / `$or` 数组因此都保
+  证非空。
+
+  **同一改动里的形状拒收**,顺序是先拒收后归约:单位元把「这个节点没有谓词」读作「匹配全部
+  文档」,所以空节点必须只有一个成因。改前实测,本驱动这一格比 `driver-sql` 当年更糟 ——
+  `{ $or: [new Date()] }` 译成 `{ $or: [{}] }`,即**每一份文档**;`{ $or: 'x' }` 与
+  `{ $not: null }` 译成 `{}`,同样是每一份文档。`updateMany` / `deleteMany` 走的是同一个
+  translate 层,在那里「放宽到全部文档」不是行数不对而是数据丢失。现在这类操作数按
+  ADR-0112 以 `INVALID_FILTER` / `status: 400` 拒收,并在消息里点出位置
+  (`filter.$or[0]`)。`Date` / `RegExp` / class 实例都满足 `typeof x === 'object'` 却枚举
+  为空,故判定按**原型**而非 `typeof`。
+
+  `packages/spec` 侧只动文档:`FilterConditionSchema` 的契约 TSDoc 写明 `$not` 的
+  **NULL-safe** 语义(#5146 维护者拍板 —— 被比较列为 NULL 的行不满足被否定的条件,应当被
+  返回,即 `NOT (…) OR col IS NULL`),并在 `filter-logic-conformance.ts` 记下三族已裁定但
+  **尚未进表**的 case 及其实测矩阵。无运行时行为变化,无 API 变化。
+
+- 414395b: fix(spec): 导航项的四条「展开」别名不再把作者指向该变体同样拒绝的键 (#5555)
+
+  `expanded` 只声明在 `group` 导航变体上,但 `defaultOpen` / `open` / `collapsed` /
+  `isOpen` 这四条别名写在 `NAV_ITEM_ALIASES` —— 一张被盖进全部九个变体的共享表。于是在
+  另外八个变体上,报错把作者指向一个下一步同样会被拒的键:
+
+  1. 写 `{ type: 'url', url: '/x', defaultOpen: true }`
+  2. 得到 `` Did you mean `defaultOpen` → `expanded`? ``
+  3. 照做改成 `expanded: true`
+  4. **再次被拒**,而且第二次没有任何建议
+
+  这正是 #4001 战役要消灭的那个失败模式(ledger finding 7 的「二次拒绝」),由该战役
+  自己的修复产生。
+
+  四条别名已挪进**按变体拼装**的那一段:`group` 保留裸键名重定向(`expanded` 在它身上
+  是真键),另外八个变体改用散文 target —— 与同一段里既有的六条跨变体别名同形:
+
+  ```
+  Did you mean `defaultOpen` → `type: 'group' (with expanded)`?
+  ```
+
+  **只改面向作者的报错文案,schema 形状没有变化**:接受与拒绝的键集合、类型、默认值
+  全部不变,已有的元数据不受影响。`group` 上的四条别名行为也不变。
+
+- b4ad984: 修正未知键「你是不是想写」兜底对 camelCase 键的系统性偏弱 (#4990)
+
+  `findClosestMatches()` 此前只把**输入**小写化,**候选不做同样处理**,于是候选键里的每一个大写字母都要额外付一次编辑距离。叠加 `strictUnknownKeyError` 长度相对的预算(短键即 2),短 camelCase 键上一个普通笔误就够不着建议了:`hideOn` 对 `hiddenOn` 真实距离 2、加大写罚分后 3、超预算返回空,而同一个词写成全小写的 `hiddenon` 反而拿得到建议 —— 把键写错大小写的作者,比写对了大小写、只错一两个字母的作者得到更好的诊断。
+
+  现在打分对两侧做同样的归一化(大小写 + `-`/空格 → `_`),回显仍用候选的原始拼写。两处附带修正:
+
+  - 折叠后距离为 0 的候选(只有大小写之差,例如 `hiddenon` → `hiddenOn`)不再被 `distance > 0` 过滤丢掉 —— 那是兜底能给出的最有把握的一条建议。过滤改为只排除作者逐字写过的那个字符串;顺带修掉一个未被记录的同源缺陷:旧实现会把作者写对的键原样回显成「你是不是想写」。
+  - 折叠后打平时,以作者自己写的大小写作为**次级**排序依据(`yxAis` 同时距 `yAxis`、`xAxis` 为 2,大写 A 指向前者)。
+
+  由于「TS config keys → camelCase」是全仓约定,这条影响 #4001 战役已落地的每一条未知键错误信息。在全部 325 组真实候选集上按单字符笔误实测:329 例从「没有建议」变为有建议(328 例正确),**0 例失去建议**,31 例改变选中项(30 例更准)。`ui/responsive.zod.ts` 中批 13 为此写的逐例 `hideOn: 'hiddenOn'` alias 已随之退役,其实测值改由 `responsive.test.ts` 的断言保存。
+
+  `data/object.zod.ts` 的 `suggestKey` 经核查**不同病**(它本来就对两侧都做了小写化),已补测试锁定,防止两处再次分叉。
+
+- a9f32df: Fix `snap.grid` on the Studio flow-builder config pointing authors at the wrong key, and gate the cause repo-wide.
+
+  `strictUnknownKeyError` indexes an alias table by `aliasProbe(key)` — lowercased, with `_`, `-` and spaces stripped. Two keys in one table that normalise identically therefore share one index, and the later entry silently overwrites the earlier one. Nothing checked for that.
+
+  `these snap settings` listed `grid: 'gridSize'` and, at the end of the same table, `grid_: 'showGrid'`. Writing `grid: 24` (the grid's pixel pitch) was answered with:
+
+  ```
+  Did you mean `grid` -> `showGrid`?
+  ```
+
+  `showGrid` is a boolean, so following that advice was rejected a second time. It now answers `grid` -> `gridSize`, and `gridSize: 24` parses. `visible` still covers the show/hide intent.
+
+  Three other tables carried a second spelling of a key they already had — `rollup`/`rollUp` on a field, `object_name`/`objectName` on a webhook, `strokeDasharray`/`strokeDashArray` on a chart series. Both spellings pointed at the same target there, so the overwrite changed nothing and no author could trip on it; the redundant entries are removed. Because the probe already folds case and separators, the surviving entry accepts every spelling the deleted one did — no authoring input changes meaning.
+
+  `alias-integrity.test.ts` now rejects any alias table containing two keys that share a probe, judged with the real `aliasProbe` rather than a copy of it, so this class cannot come back.
+
+- aeb9b27: **发布出去的 OpenAPI 文档 `components.schemas` 不再是空的,6 个 `$ref` 不再悬空(#5168)**
+
+  `GET /api/v1/openapi.json` 的 base spec 由 `packages/spec/scripts/build-openapi.ts` 生成,它把九个契约 schema(`CreateRequest` / `ApiError` / `ListRecordResponse` / …)转成 JSON Schema 填进 `components.schemas`。收集判据写的是 `typeof schema === 'object' && '_zod' in schema`,而这九个 schema 全部经 `lazySchema()` 包装 —— 其 Proxy target 是 `function lazyZod() {}`,于是 `typeof` 是 `'function'` 而不是 `'object'`,判据第一段就短路,九个一个都没进去。`paths` 里那 6 个 `$ref` 是手写字面量,不受影响照常写出,结果是**一份 `components.schemas` 为 `{}`、6 个 `$ref` 全部悬空的文档被发布出去**,覆盖 `/api/{object}` 与 `/api/{object}/{id}` 上全部 CRUD 操作的请求体与响应体。
+
+  判据放宽为同时接受 `'object'` 与 `'function'`。`'_zod' in schema` 那一段对 Proxy 本来就是有效的 —— `lazySchema` 专门维护了 `_zod` facade 供 `toJSONSchema` 遍历 —— 所以 `lazySchema` 本身不需要改动。对照实验坐实了唯一变量就是 Proxy:同一份源码下 `npx tsx scripts/build-openapi.ts` 得到 `Components: 0`,而 `OS_EAGER_SCHEMAS=1`(`lazySchema` 自带的绕过 Proxy 应急开关)得到 `Components: 9`。修复后不带任何环境变量即为 `Components: 9`。
+
+  两类消费者直接受益:`GET /api/v1/docs` 的 Scalar viewer 现在有 schema 可渲染;从该文档做客户端代码生成的集成方(openapi-generator / orval / …)不再在解析期撞上 unresolvable reference。
+
+  **同时补上防复发的门禁。** 这个缺陷三个层次同时可见(空 components、悬空 ref、控制台明晃晃的 `Components: 0`)却没有任何一处红 —— `gen:openapi` 是全仓两个完全无门禁的生成器之一。生成器现在在**写盘之前**自检两条,任一不满足即以非零码退出,自恰不了的文档根本不会被写出来:
+
+  1. **每个本地 `$ref` 都必须解析得到。** 按 JSON Pointer 解析而不是按 `#/components/schemas/` 前缀匹配,将来新增的 `#/$defs/…` 引用自动被覆盖;报错逐条点名悬空的 `$ref` 及其在文档中的位置,并把「已定义的 schema 列表」一并打出来 —— 哪一侧是空的是读者最先需要的信息。
+  2. **没有 schema 被静默降级。** 九个契约 schema 是一张字面清单,某个名字没产出东西永远是缺陷而不是「这个可选」。原先的循环写成 `if (像 zod) { 收 }` 且没有 `else`,正是这个「静默跳过」的形状让九次跳过发布成了空文档;现在**声明即强制**,漏掉的名字会被点名。`z.toJSONSchema()` 抛错时原先会塞一个 `{type:'object'}` 占位描述冒充契约,这条同样改为响亮失败 —— 当前九个全部干净转换,零占位。
+
+  门禁接在生成器内部而不是单独的 `check:` 脚本,因为 `packages/spec/json-schema/` 是 gitignore 的、每次 `pnpm build` 重新生成,独立检查脚本无论如何都要先跑一次生成器才有东西可查。「产物自恰」这类断言比「产物最新」更便宜,且不需要任何基线快照。
+
+  `packages/rest` 侧无行为改动:声明式端点的 enrichment 仍然只写 `type: object` 而不编造 `$ref` —— 九个契约 schema 是通用 CRUD 信封,不是某个具体对象的 body 形状 —— 但三处以现在时陈述「`components.schemas` 是空的」的注释已按事实更新。
+
+- e4c8b6c: fix(spec): protocol-17 迁移步骤的 rationale 不再声称「服务端不走 `areas`」—— 该边界已由 #4722 在同一大版本内关闭 (#5337)
+
+  `MIGRATIONS_BY_MAJOR[17].rationale` 里的 app-area 段落还带着 #4651 退役当时写下的
+  caveat:
+
+  > per-item gating INSIDE an area is enforced by the shell only, since the server
+  > does not walk `areas`, so anything that must never reach the browser belongs in
+  > the top-level tree or in its own app.
+
+  **#4722 之后这句已不成立**,而且它是以现在时写给读者的操作建议。`filterAppForUser`
+  现在对每一棵 `areas[].navigation` 跑同一个 `filterNav`(`packages/rest/src/rest-server.ts`),
+  导航**项**的 `requiredPermissions` / `requiresService` 在两棵树被同等强制、被门禁掉的条目
+  根本不会出现在 `/meta` 响应体里。
+
+  这段 prose 不是注释:`docs/protocol-upgrade-guide.md` 是它的纯投影(ADR-0087 D4,
+  `gen:upgrade-guide`),也就是**正在从 16 升到 17 的作者**读的那一页。原句会劝他为一个如今
+  可以就地写下的门禁去重构整棵导航树。#4722 与 #4651 落在同一个 17.0.0 窗口内,所以读这份
+  指南的人所处的世界已经是「服务端走两棵树」。
+
+  改后措辞与 PR #5336 落地的 schema 侧处方(`AREA_VISIBLE_RETIRED` /
+  `AREA_REQUIRED_PERMISSIONS_RETIRED`)、以及 `packages/spec/liveness/app.json` 的
+  `areas.navigation` 记录一致:
+
+  - **保留历史**:退役当时的状态叙述(为什么选 route B 而非 route A)原样保留,只是把时态
+    锚在「At the time of the retirement」,免得历史被读成现状;
+  - **点名 #4722**:命名两棵树、命名 `areas[].navigation`;
+  - ⛔ **不复活 area 级键**:`app.areas[].visible` / `app.areas[].requiredPermissions`
+    依然退役,#4722 强制的是 area **内部的项**,area 自身没有门;
+  - ⛔ **不带歪 `visible` 的口径**:`visible`(CEL)与 `requiresObject` 在**每一层**仍然只在
+    客户端求值 —— 服务端 CEL 需要一个读取层没有的 `user` 绑定 —— 所以绝不可到达浏览器的东西
+    写在 `requiredPermissions`,永远不要写在 `visible`。
+
+  未发布的 `.changeset/app-area-fail-open-gates-removed.md` 里同一句一并订正(仓库处于
+  changesets pre 模式,该文件仍是 v17 GA 发布说明的法定输入)。`docs/protocol-upgrade-guide.md`
+  由 `gen:upgrade-guide` 重新生成,未手改。
+
+- a34fd2e: `check:react-declaration-parity` had no path on which it could go red — a missing manifest now fails instead of skipping, and the ledger says "cannot run here" instead of "deliberately not run".
+
+  Two things stacked. The gate was in **no workflow** (`grep -rl check:react-declaration-parity .github/workflows/` returned nothing), and a manual run without `MANIFEST` printed `⚠ manifest unavailable … — skipping.` and **exited 0**. So the one gate whose history is written up in AGENTS.md as worth keeping — `spec-only` / `registry-only` / `missing` are real signals — could not fail for anybody, ever. Two other issues had already started citing it as the negative example of a gate that cannot be shown to catch anything (#4804 / #4777).
+
+  **Where the manifest comes from, measured before anything was wired.** The right-hand side is objectui's `sdui.manifest.json`, and this repository cannot produce one: its only producer drives a real browser at objectui's built console and reads `window.__MANIFEST` (the registry pulls browser-only deps, so nothing enumerates it from Node). `packages/console/dist/` is gitignored, `scripts/build-console.sh` deliberately does not dump one — it must not drag a browser into the console build — and the published `@objectstack/console` tarball contains no `sdui.manifest.json` either (16.1.0: 513 files, zero `sdui` matches; its `dist/manifest.json` is the PWA manifest, so even the CLI's `@objectstack/console/dist/sdui.manifest.json` fallback resolves to nothing). Wiring a step into `lint.yml` would therefore have wired a **permanently skipping** step — the same defect with CI decoration.
+
+  - **"Could not run" is now a failure, not a skip.** No `MANIFEST`, a path that does not exist, malformed JSON, or a dump declaring zero components each exit **1** with a prescription that names the producer (`pnpm sdui:manifest`, `OBJECTUI_ROOT=../objectui pnpm objectui:build`) and the browser it needs. Deliberately independent of `--strict`: that flag prices a _divergence_, and this is the other thing entirely — no comparison happened. The empty-dump case is new coverage in the same family; objectui's dumper already refuses to _write_ one, and this refuses to _read_ one instead of reporting every block as missing.
+  - **The ledger stops implying someone runs it.** `check:generated` moves it out of `NO_GENERATOR` ("runnable, deliberately not run here") into a new `EXTERNAL_INPUT_REQUIRED` bucket that records the missing input and its producer, and prints `cannot run here: check:react-declaration-parity — needs MANIFEST=…; runs in scripts/gen-sdui-manifest.sh`. Following `EXPLICIT_GENERATORS` (#5358/#5807), the classification carries an enforced claim rather than a label: the reconciliation fails if `scripts/gen-sdui-manifest.sh` stops **invoking** the gate on a non-comment line — a gate filed as "runs elsewhere" while running nowhere is the exact hole this bucket exists to expose.
+  - **The gate is now demonstrably able to fail.** `check-react-blocks-declaration-parity.test.ts` asserts exit codes, not just report text: a fabricated registry-only input and a vanished block each exit non-zero **naming themselves**, all four "could not run" paths exit non-zero, and an accepted state still exits 0 so the red is discriminating. The pre-existing helper swallowed exit codes by design, so every earlier test would have passed against a script that always exited 0 — which is what this gate was.
+
+  Where the manifest should come from in CI (an objectui clone plus a browser in this repo's workflows, a published manifest artifact, or a Node-side dump in objectui) stays an open provenance decision, filed separately. Until it is answered, the honest state is a gate that runs at `pnpm sdui:manifest` and refuses to pretend otherwise.
+
+- 7adc841: fix(spec): 退休登记按**确切 key** 判定 —— 无关簇的同名叶子不再让 tombstone 冒充「已登记」(#4659)
+
+  `scripts/build-schemas.ts` 的检查 (b)(`check:authorable-surface`)保证一件事:
+  一个 authorable key 从 live 翻成 retired(`retiredKey()` 墓碑)时,这次退休必须
+  被登记下来,否则 `spec-changes.json`(ADR-0087 D4)、生成的升级指南、`spec_changes`
+  MCP 工具全是空的,消费者只能靠失败才知道。
+
+  它此前是这样判定「已登记」的:取 key 的**叶名**,拿去和**全部 major** 的所有
+  conversion / migration `surface` 子句做 `endsWith('.' + name)` —— 完全不看 key
+  属于哪个 def。于是任何一条无关登记,只要 surface 以同名叶子结尾,就把这个墓碑判为
+  「已登记」:
+
+  - #4658 实测:`automation/Event:type` 被 tombstone、零 conversion,门禁全绿 ——
+    命中的是 protocol 11 的 `flow-node-http-callout-rename`(`flow.node.type`),
+    一个 flow 节点的 `type`,和状态机事件毫无关系。
+  - #5509(ADR-0087 D2 `page-header-subtitle-alias`)登记
+    `page.component.page-header.description` 之后,任何叶名为 `description` 的 key
+    也进了同一个免检名单。`type` / `name` / `config` / `filter` / `schema` /
+    `description` 都是 authorable 形状上最常见的叶子,这条保证对它们整体失效。
+
+  现在登记有了自己的表:
+
+  - **新增导出 `RETIRED_KEYS_BY_MAJOR`**(`@objectstack/spec`,
+    `src/migrations/registry.ts`),值就是确切的 `` `${defKey}:${name}` `` 字符串 ——
+    `authorable-surface.json` 怎么写它就怎么写,去掉 `[RETIRED]` 标记。
+  - 检查 (b) 改为对这张表做**精确集合判定**:不再有 `endsWith`,不再取叶名,不再从
+    相邻的 key 辐射过来。门禁失败时直接打印要粘贴的那一行和它该进哪个 major。
+  - 新增检查 (b2):表里登记了一个**当前仍然 live** 的 key —— 一次没有任何东西消费的
+    登记 —— 直接失败;它会替一次尚未发生的退休提前放行。登记了一个本次构建**已不再
+    产出**的 key 则不是错误:墓碑满 ~2 个 major 之后由检查 (c) 放行其基线行,登记条目
+    留下,这是预期稳态。
+
+  conversion 的 `surface` 保持散文形态、一个字没动:它面向作者、按作者书写元数据的
+  形状表达(`flow.nodes[].outputSchema`),本来就无法可判定地映射回 def key。所以
+  搬走的是机器事实,不是散文。一次退休仍然两样都要写:登记条目是**声明的凭据**,
+  conversion 是**消费者照着做的处方**。
+
+  不回填历史:检查 (b) 只在相对已提交基线的 live → retired **新**跃迁上触发,而更早的
+  墓碑在基线里已经是 `[RETIRED]`,不会再触发它。所以这张表读作「在确切-key 门禁下登记的
+  退休」,不是「历史上的全部退休」—— 空表在 `main` 上实测全绿。
+
+- 7b005b4: Generate the root reference index (`content/docs/references/index.mdx`) instead of leaving it ownerless.
+
+  That page sat in the AUTO-GEN zone — which the Documentation Guardrails forbid hand-editing —
+  while `build-docs.ts` never wrote it, so it could only rot, and it had: rows for
+  `automation/trigger-registry.zod.ts` and `automation/sync.zod.ts` (deleted at #4499 / #4738),
+  schema names that were never exports (`TriggerRegistrySchema`, `SyncSchema`, `ETLSchema`), a
+  nine-row section for a `src/hub` directory deleted long ago, a `shared/connector-auth.zod.ts`
+  row for a file `@objectstack/spec/shared` does not publish, three mutually contradictory totals
+  (133 / 169 / 19-under-a-heading-of-18), and two dead "Next Steps" cards.
+
+  The per-module tables are now enumerated from the same JSON Schema output the category pages are
+  built from, so a deleted `.zod.ts` cannot leave a row behind, a name the spec does not publish
+  cannot appear, and every count is a sum of the rows it heads. The page now lists all 1608
+  published schemas against the 201 files that declare them. `check:docs` covers it like any other
+  generated file.
+
+- 94f7b6a: fix(spec,runtime): `EngineSchemaRegistryView` now declares the six package-lifecycle members it always had (#4311).
+
+  `getPackage` / `installPackage` / `uninstallPackage` / `enablePackage` / `disablePackage` /
+  `updatePackageManifest` are additions to the exported `EngineSchemaRegistryView` type only —
+  `SchemaRegistry` has implemented all six since long before the contract existed, and three
+  packages outside the engine already call them (`runtime`'s `/packages` domain handler,
+  `metadata-protocol`'s install/update primitives, `service-package`'s hydration). The contract
+  landed in #4404 declaring eight members; these six were missed, and nothing caught it because
+  `@objectstack/runtime` had no `typecheck` script to read the caller. Zero runtime behaviour
+  change: no implementation, call site or response shape moves.
+
+  `@objectstack/runtime` itself is not released by this change — it gains a `typecheck` script and
+  loses its `check-type-check-coverage` DEBT entry, plus type-only annotations (unused parameters
+  renamed to `_`-prefixed, one unused import dropped).
+
+- ae490ef: feat(mcp): 开源发行版终于消费 skill —— `instructions` 半边投影为 MCP `prompts` 原语 (#3905)
+
+  `stack.zod.ts` 与 ADR-0063 §2 把 **skill 定为唯一第三方扩展原语**,而开源发行版
+  (BYO-AI,cloud ADR-0025)里零消费方:`SkillSchema` 可作者化、被两条 lint 规则认真
+  校验(`validateAiToolReferences` / `validateAiSurfaceAffinity`),却没有任何代码路径
+  读它 —— 作者写 skill → 校验通过 → lint 通过 → **永不运行且无人告知**。这正是本仓
+  ratchet 存在的意义所要消灭的 declared ≠ enforced 形状。
+
+  **skill 的两个半边,现在各自说清楚跑在哪。**
+
+  - **`instructions`(判断力)→ MCP `prompts` 原语,处处可用。** MCP 服务器补齐了
+    `prompts/list` / `prompts/get`:每个带 `instructions` 的已注册 skill 成为一个
+    MCP 客户端可以列出并取回的 prompt(prompt 名 = skill 机器名,`label` → `title`,
+    `description` 原样带上)。HTTP 与 stdio 两条传输都服务它。
+  - **`tools` / `surface` / `triggerConditions`(接线)→ 明确标注 cloud-runtime-only。**
+    绑工具与激活判定是 in-product agent 循环的属性;MCP 里模型在客户端、服务端只有
+    一张扁平工具表,AI 暴露的 Action 早已通过 `list_actions` / `run_action` 可达。
+    文档与 schema JSDoc 如实写明,不再装样子 —— 但两半边在两个发行版里都照旧接受
+    **校验**,所以开源里写的 skill 到 cloud 上语义完整,不必写两遍。
+
+  **协议合规。** `prompts` 能力按规范声明:只有当宿主能读到本环境的 skill 元数据时
+  才声明并注册处理器(能力协商如实,与 action 工具同一套优雅降级);无 skill 时
+  `prompts/list` 返回**空列表而非报错**;`prompts/get` 取不存在的名字返回
+  `-32602 InvalidParams`;没有 `instructions` 的 skill 与 `active: false` 的 skill
+  不投影。HTTP 面的投影从**本请求自己的 bridge** 读(与 `describeObject` 同一条
+  per-environment 通道),多租户宿主不会把一个环境的 skill 服务给另一个环境。
+
+  **同时修掉同仓重名。** `packages/mcp/src/skill.ts` 从来不是 skill 元数据类型,
+  而是 ADR-0036 Amendment C 的 `SKILL.md` 分发物 —— 在 `packages/mcp` 里 grep
+  `skill` 先找到的一直是它。现在按各自承载的产物命名:`skill-md.ts`(SKILL.md
+  分发物)与 `skill-prompts.ts`(skill 元数据 → prompts 投影),两侧模块头互指。
+  包的公开导出名(`renderSkillMarkdown` / `OBJECTSTACK_SKILL_NAME` /
+  `OBJECTSTACK_SKILL_DESCRIPTION` / `RenderSkillOptions`)一个未变。
+
+- e3ef52b: refactor(spec): 三个热点生成物按 category / entrypoint 分片,合并队列的串行税消失 (#5837)
+
+  `merge=os-regen`(#4675)只在**本地** git 生效。合并队列在服务端重建 PR 时不跑自定义
+  merge driver,所以两个都动过 `authorable-surface.json`(310KB、7941 行排序数组,每个
+  spec PR 都会重写)的 PR 在队列里是纯文本冲突,第二个必然被踢——spec 车道一次只能放行
+  一单。driver 自己的注释里记着这笔税的形状:一个下午 4 次合并 9 处冲突,**零**真语义
+  冲突,全部是集合并集。付的是「单体文件」这个形状的钱,不是分歧的钱。
+
+  **布局变化(发布产物路径,见下方档位说明)**
+
+  | 之前                                      | 现在                                                   | 分片键                        |
+  | :---------------------------------------- | :----------------------------------------------------- | :---------------------------- |
+  | `packages/spec/authorable-surface.json`   | `packages/spec/authorable-surface/< category >.json`   | def key 的 category 段        |
+  | `packages/spec/json-schema.manifest.json` | `packages/spec/json-schema.manifest/< category >.json` | 同上                          |
+  | `packages/spec/api-surface.json`          | `packages/spec/api-surface/< entry >.json`             | 已发布入口(`.` → `root.json`) |
+
+  有意维持单体:`spec-changes.json`(按版本键控)、`api-surface-signatures.json`(1.3KB)、
+  `authorable-surface.base.json`(只有显式 `--update-base` 会写,从不在 churn 路径上,且
+  它的 `baseRev` 是整个 surface 的**一个** commit——分片会让不同分片镜像不同 revision,
+  那是任何上游 commit 都没有过的状态)。
+
+  **ratchet 语义逐条不变。** 所有门禁读**整个目录**当作一个集合,而不是「这次构建会写的
+  那些分片」:删掉一整个分片文件 = 删掉它的 key,checks (a)/(c) 看到的缺失 key 与从前删
+  单体文件里的行时一模一样;没人重生成的分片报**陈旧**而不是被跳过;#4662 的逐字节规范
+  形式比对现在是逐分片做的,手改因此还能被**指名到文件**。#5976 的 def key 撞名守卫不受
+  影响——它按剥后缀的 schema 名判定(`shared/HttpMethod`),与输出路径无关,且仍在两个
+  ratchet 之前运行。
+
+  **对消费者的可见影响,以及为什么是 patch。** `@objectstack/spec` 的 `files` 里
+  `api-surface.json` 改成了 `api-surface`,所以 npm 包内该快照的路径变了(它不在
+  `exports` 里,不是可 import 的子路径,是给工具读的文件)。导出面本身**零变化**
+  (`check:api-surface` 实测 0 breaking / 0 added),运行时行为、类型、schema 一律未动,
+  因此不是 major;仓内唯一的读点(release 工作流的 surface diff)随之更新,并且会按上游
+  tarball 实际携带的形状读取——`api-surface/` 目录(本次起)、`api-surface.json` 单文件
+  (protocol 15 起至本次)、两者皆无(protocol 15 之前)。外部若有直接读
+  `node_modules/@objectstack/spec/api-surface.json` 的工具,改读 `api-surface/` 目录并把
+  各分片的 `exports` 按 `entry` 合并即可,内容逐条相同。
+
+- 07f1822: feat(spec): `FILTER_LOGIC_ROWS` 新增可空列 `d`,`FILTER_LOGIC_CASES` 收入 `$null` 用例
+
+  跨后端 filter conformance 表此前**刻意不含**任何空值处理,自陈理由是「三值 SQL 引擎
+  与两值 JS 匹配器无法被同一个答案约束」。#5146(`$not`)与 #5298
+  (`$ne`/`$nin`/`$notContains`)两次裁定取消了这个前提:「该列没有值」现在有唯一的
+  跨后端答案,于是它和其他语义一样属于这张标准表。
+
+  **给第三方驱动作者的迁移要点。** `FilterLogicRow` 新增 `d: string | null`
+  (第 1-2 行有值,第 3-4 行为 NULL)。用这张表校验自建后端时:
+
+  - DDL / schema 声明里必须把 `d` 声明为**可空**。`NOT NULL` 列,或把 `null` 替换成
+    `''` 的 seed,会让新用例因为**错误的原因**变绿 —— 这两条用例要测的恰恰就是
+    「一行没有值」时发生什么,fixture 里没有这样的行就什么都没测到。
+  - 新增两条用例:`{d: {$null: true}}` → `['3','4']`,`{d: {$null: false}}` → `['1','2']`。
+    互补的两条一起入表,是为了把 `$null` 钉成对整表的**划分**,而不是其中一半 ——
+    这样一个 `NOT NULL` 的 fixture 列会响亮地失败,而不是安静地全绿。
+
+  单独开一列而不是把 `a` / `b` 挖空:`(a, b)` 的 2x2 真值表是「一对谓词被错误 OR 起来
+  必然多出 id」的依据,在它上面开洞会为了空值用例削弱每一条组合子用例。
+
+  同批订正了模块文档的两处事实错误:独立实现的计数由「五个」改为**七个**(补上
+  `driver-turso` 的 `RemoteTransport.buildWhereSQL` 与 `service-analytics` 的
+  `filter-normalizer` —— 两者都是手写发射器,#5298 实测它们对空值族的答案与其余五个
+  不同),以及原先「#5146 一族 every surface answers the same way」的说法(它漏掉了
+  turso remote,该分叉由 #5903 跟踪)。
+
+  `$ne` / `$not` 两条对应用例**尚未入表**:实测 `driver-turso` remote(#5903)与
+  `filter-normalizer`(本裁决第二批)还答不出来,而一条已知会红的用例不能强制任何裁决,
+  只会把别的车道的未完成工作变成这张表的失败。它们随各自的修复 PR 入表 —— 模块文档的
+  「RULED but not yet enrolled」小节里写好了实测矩阵与两个 blocker。
+
+- 04fab5e: fix(spec): the authorable-surface deletion gate no longer needs network to build (#5235)
+
+  `gen:schema` anchors the #4650 deletion check on `authorable-surface.json` at the merge
+  base with `origin/main` — the one version of that file the commit under test cannot
+  rewrite. When `origin/main` could not be resolved (and the self-heal `git fetch` could not
+  make it resolvable), the build failed:
+
+  ```
+  ❌ Cannot resolve origin/main to anchor the authorable-surface deletion check (#4650).
+  ```
+
+  That is correct for a developer who forgot to fetch, and wrong for an entire class of
+  build environments that have no route to GitHub at all: image-build stages that copy a
+  SHA-pinned framework tree into a container and build it there, air-gapped builds, forks,
+  and historical-tag reproductions. Those trees are immutable and already merged — there is
+  no "what did this PR delete relative to main" question to ask — yet the gate failed them
+  anyway. It blocked every downstream consumer that builds `@objectstack/spec` from a pinned
+  checkout without network.
+
+  The baseline is now also committed to the tree as `packages/spec/authorable-surface.base.json`:
+  the keys of `authorable-surface.json` as of `baseRev`, a commit on `origin/main`.
+
+  - Where `origin/main` is reachable (every dev checkout, every CI run) nothing changes: the
+    gate still anchors on the merge base, and it additionally verifies the committed anchor
+    against it — `baseRev` must be an ancestor of `origin/main` and the recorded keys must
+    be that commit's baseline. So a commit cannot edit the anchor to hide a deletion; the
+    environments that can check, do.
+  - Where `origin/main` is not resolvable, the gate anchors on the committed file and the
+    build proceeds. It still runs: a key the anchor records that the build no longer emits
+    is as fatal as before. Only an authoritative anchor may write the file, so an offline
+    build can never advance it to its own state.
+
+  There is deliberately no environment-variable skip — a deletion check that can be switched
+  off is the bypass #4650 exists to close. With neither anchor available the build still
+  fails.
+
+- ba98e26: tooling: strictness 台账「数字/散文分家」—— 计数转生成物走 os-regen,判定与依据保持手写 (#5107, #5072)
+
+  `docs/audits/2026-07-unknown-key-strictness-ledger.md` 是战役期间全仓最热的合并冲突点,而冲突全部落在它的**数字**上:两个批次各按自己那份正确的增量去减表头,git 把互不重叠的**行**干净合并,而与谁都不冲突的**小计行**「干净合并、两边都错」—— 单日 7 例,`ui/` 小计被三个批次分别写成 119 / 110 / 100,而合并后的正确值 91 三边都没写过。**散文当天只冲突过一次,而且那次是有意义的。**
+
+  所以数字走了。新增生成物 `docs/audits/2026-07-unknown-key-strictness-ledger.counts.md`(`gen:strictness-ledger`),承载每文件站点数/strip 数、各段表头、按类小计、posture 分布与未细分目录的总数;`.gitattributes` 把它加进 `merge=os-regen`(#4675),合并时不做文本合并、整体重生成,`pre-commit` 在重生成之前拒绝提交。台账本体只留承重的部分:`Class` 判定、依据、findings log、豁免记录 —— 这些是判断,不是算术,重生成会**删掉别人的证据**,所以 `docs/audits/**` 仍在 `NOT_DRIVER_MANAGED` 里。
+
+  `check:strictness-ledger` 的职责随之反转,双向闸语义完整保留:
+
+  - **生成物新鲜**:整份重新渲染后逐字节比对,失败信息把「某个数字动了 = 有 schema 在没人重新审视的 `Class` 判定下被增删/改姿态」这句话说出来 —— 这正是旧的手写计数唯一值得留下的那一半;
+  - **散文自洽**:每条手写行必须指向一个仍然存在、仍然有站点的文件(旧的计数检查顺带买到的性质),有站点却没有行仍然红,strip 行归零仍然红(反向钉)。
+
+  两条红路径都先证了红再信绿:改生成物里一个数字 → EXIT=1;删一条手写行 → EXIT=1(并且被删的行不会静默变成 0,它会以 `⚠️ unclassified` 出现在生成物里)。
+
+  小计是「对判断做算术」,所以 remaining-strip 那张表的 `Class` 单元格现在有语法:`<verdict> [(p)] [· <n> <verdict>, …]`。已解决的 `mixed`/`split` **必须**声明自己的拆分,闸门拒绝猜 —— 一个宽容的解析器会把这些数字原封不动地送回它们刚被搬走的地方,而且是在一个绿色的文件里。迁移后所有已发布的数字逐一复现(235 strip / 36 open files / authorable 29 / unresolved 33 / no door 38 / no gate 31)。
+
+  **同一把尺的搭车修复(#5072)**:`postureOf()` 对战役自己的 helper 短路 —— `strictObject(` 直接返回 `strict`,不看链上挂了什么,于是 `strictObject(…).passthrough()`(运行期**开放**的形状)在台账里被记成 **strict**。全仓恰好 2 处,都在 `ui/view.zod.ts`(`GanttConfigSchema` / `TreeConfigSchema`),两处的 `.passthrough()` 都是刻意的。现在 idiom 只决定**起始**姿态,链一律走完,最后一个显式调用赢。`ui/` 的 strict 读数 119 → 117、passthrough 3 → 5;**strip 计数不变**,所以 remaining-strip 那张双向表的数字一个都没动。零 `*.zod.ts` 语义改动。
+
+- 8064b07: **A view filter rule carrying the console's UI row `id` no longer 422s (#5114).**
+
+  `ViewFilterRuleSchema` had been closed to unknown keys by an earlier strictness
+  wave. The filter builder the console renders stamps `id: crypto.randomUUID()` on
+  every filter row it creates (a React list key), and the metadata write path
+  validates the PUT body and then persists the **authored** body verbatim — so the
+  `id` is on the wire, and in already-stored view rows. Closed, the schema rejected
+  it: every filter write carrying one came back `422 Unrecognized key(s) on this
+view filter rule: 'id'`. Measured on all three paths, including the flattened
+  personalization overlay that is the shape the console PUTs.
+
+  ⚠️ **This does not on its own restore "save a filter from the console".** Browser
+  verification found a second, independent defect stacked on the same request: the
+  list toolbar persists the filter builder's whole `FilterGroup` object (`{ id,
+logic, conditions }`) into `filter`, where the spec declares `ViewFilterRule[]` —
+  a type mismatch that rejects before the `id` is ever reached. That one belongs to
+  the producer and is tracked separately; until it lands, the console's filter save
+  still fails. What this change fixes is every writer that sends a well-formed
+  `ViewFilterRule[]` whose rows carry the UI `id` — including view rows already
+  stored with one.
+
+  The shape is reopened (unknown keys are dropped again, as before the closure).
+  `id` is deliberately **not** declared: it is a UI artifact, and declaring it would
+  put it on the authorable surface and tell an AI author to generate a UUID for a
+  filter rule. Nothing else changed — the operator vocabulary, the legacy-spelling
+  normalization and the required `field` all still validate, so an invented operator
+  is still rejected.
+
+  Worth knowing for anyone tightening a neighbouring block: **`.strip()` does not
+  recurse**, any more than `.strict()` does. `ViewMetadataSchema` re-opens its
+  flattened members so Studio's round-trip keys ride along, but that re-opens the
+  top level only — a nested block closed inside the list view is still reached
+  through that member, so a console-stamped key inside it 422s regardless. The
+  durable fix is the authoring/wire split tracked in #5074, which this site is now
+  named in; the verdict is recorded on the schema, in
+  `view-filter-rule-wire-id.test.ts`, and in the `ui/` row of the strictness ledger.
+
+- 4a56dbd: fix(spec): 视图标签 / 描述现在能真正解析出译文(#4854)
+
+  `resolveViewLabel` / `resolveViewDescription` 读取的两个字段,运行时实际下发的
+  视图文档一个都没有,因此**任何按正常方式(`defineView`)编写的视图,标签永远
+  落回英文字面量**,无论翻译包里写了什么。列表视图切换器横在每个对象列表页顶部,
+  所以在纯中文部署里,这是屏幕上最显眼的一处残留英文。
+
+  两处失配互相独立,任何一处都足以让解析失败,现已一并修复:
+
+  1. **对象名取不到。** 旧代码读 `view.objectName ?? view.data?.object`;而
+     `GET /api/v1/meta/view?object=…` 下发的文档把对象放在**顶层 `object`**,
+     授权配置嵌在 `config` 下。于是 `objectName` 为 `undefined`,函数在
+     `if (!bundle || !objectName)` 处就返回了字面量,根本没走到查找。
+     现在按 `objectName → object → data.object → config.data.object` 依次取值,
+     与 i18n 提取器(`packages/cli/src/utils/i18n-extract.ts`)判定对象的顺序
+     一致 —— 写 `_views` 键的那一端和读它的这一端,从此对"哪个字段代表对象"
+     有相同答案。
+  2. **查找键也是错的。** 旧代码用 `view.name` 直接查;而下发文档的 `name` 是
+     注册表分配的全局唯一身份 `<object>.<viewKey>`(如
+     `crm_account.account_gallery`),翻译包按**裸键**存放
+     (`objects.<object>._views.<viewKey>.label`)。现在查找前先剥掉
+     `<object>.` 前缀 —— 这是对 `expandViewContainer` 组装规则的**反解**,不是
+     容错别名;没有前缀的名字(手工构造的视图)原样使用,行为不变。
+
+  **非破坏性。** `ViewLike` 仅新增两个可选字段(`object`、`config`),既有调用
+  方式全部照旧;之前能解析的场景没有一个改变结果 —— 在此之前,下发文档这条路径
+  上本就没有任何东西能解析成功。应用侧无需改动:`_views` 的键仍然是编写视图时
+  用的裸键。
+
+  已知遗留(不在本次修复范围,另行跟踪):只声明了默认 `list`(没有 `listViews`)
+  的容器仍解析不出译文 —— 提取器写的键是 `list`,而组装器给它的注册名是
+  `<object>.default`。这是两个**生产方**之间的分歧,须在生产端统一,不能靠消费端
+  再加一层兼容。
+
 ## 17.0.0-rc.2
 
 ### Major Changes
diff --git a/packages/spec/package.json b/packages/spec/package.json
index bf5f19c634..5883456e2f 100644
--- a/packages/spec/package.json
+++ b/packages/spec/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/spec",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "description": "ObjectStack Protocol & Specification - TypeScript Interfaces, JSON Schemas, and Convention Configurations",
   "license": "Apache-2.0",
   "main": "dist/index.js",
@@ -213,7 +213,7 @@
     "check:empty-state": "tsx scripts/liveness/check-empty-state.mts",
     "check:variant-docs": "tsx scripts/check-variant-docs.mts",
     "gen:strictness-ledger": "tsx scripts/build-strictness-ledger-counts.mts",
-  "check:strictness-ledger": "tsx scripts/check-strictness-ledger.mts",
+    "check:strictness-ledger": "tsx scripts/check-strictness-ledger.mts",
     "gen:react-blocks": "tsx scripts/build-react-blocks-contract.ts",
     "check:react-blocks": "tsx scripts/build-react-blocks-contract.ts --check",
     "check:react-declaration-parity": "tsx scripts/check-react-blocks-declaration-parity.ts",
diff --git a/packages/triggers/trigger-api/CHANGELOG.md b/packages/triggers/trigger-api/CHANGELOG.md
index 8f438683a9..2c6f1ffbbd 100644
--- a/packages/triggers/trigger-api/CHANGELOG.md
+++ b/packages/triggers/trigger-api/CHANGELOG.md
@@ -1,5 +1,134 @@
 # @objectstack/trigger-api
 
+## 17.0.0-rc.4
+
+### Patch Changes
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [b746aa0]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [d9971d3]
+- Updated dependencies [eb3e650]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [46365ab]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [c5adfe1]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/core@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Patch Changes
diff --git a/packages/triggers/trigger-api/package.json b/packages/triggers/trigger-api/package.json
index f70842a855..1838006d5d 100644
--- a/packages/triggers/trigger-api/package.json
+++ b/packages/triggers/trigger-api/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/trigger-api",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "Inbound HTTP/webhook flow trigger for ObjectStack — per-flow HMAC-verified endpoints with queue-backed ingestion (ADR-0041)",
   "main": "dist/index.js",
diff --git a/packages/triggers/trigger-record-change/CHANGELOG.md b/packages/triggers/trigger-record-change/CHANGELOG.md
index f489c99545..deb8d4b8a2 100644
--- a/packages/triggers/trigger-record-change/CHANGELOG.md
+++ b/packages/triggers/trigger-record-change/CHANGELOG.md
@@ -1,5 +1,145 @@
 # @objectstack/plugin-trigger-record-change
 
+## 17.0.0-rc.4
+
+### Patch Changes
+
+- 340a34f: record-change trigger: drop the unreachable `input.doc` alias read, seed the flow record from `input.data` only
+
+  Behaviour is unchanged: no engine path has ever built `input.doc`, so the alias
+  limb could not be reached. Every ObjectQL write context spells the payload
+  `data` — measured and pinned by `hook-input-shape-contract.test.ts` in
+  `@objectstack/objectql` ("insert carries `data` — never `doc`", #5273). The
+  branch survived only because the old `HookContext.input` contract table
+  documented insert as `{ doc, options }`; that table was corrected in #5668, so
+  the fallback no longer had even a documented producer to defend against, and it
+  is removed here rather than left as a second de-facto contract (PD #12).
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [b746aa0]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [d9971d3]
+- Updated dependencies [eb3e650]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [46365ab]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [c5adfe1]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/core@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Patch Changes
diff --git a/packages/triggers/trigger-record-change/package.json b/packages/triggers/trigger-record-change/package.json
index 3357cc971d..97d77a05ae 100644
--- a/packages/triggers/trigger-record-change/package.json
+++ b/packages/triggers/trigger-record-change/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/trigger-record-change",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "Record-change flow trigger for ObjectStack — auto-launches flows on object insert/update/delete via ObjectQL lifecycle hooks (ADR-0018)",
   "main": "dist/index.js",
diff --git a/packages/triggers/trigger-schedule/CHANGELOG.md b/packages/triggers/trigger-schedule/CHANGELOG.md
index ccdac0105b..074b7c6f4c 100644
--- a/packages/triggers/trigger-schedule/CHANGELOG.md
+++ b/packages/triggers/trigger-schedule/CHANGELOG.md
@@ -1,5 +1,134 @@
 # @objectstack/plugin-trigger-schedule
 
+## 17.0.0-rc.4
+
+### Patch Changes
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [b746aa0]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [d9971d3]
+- Updated dependencies [eb3e650]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [46365ab]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [c5adfe1]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/core@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Patch Changes
diff --git a/packages/triggers/trigger-schedule/package.json b/packages/triggers/trigger-schedule/package.json
index 4695c676bb..cbc7077a3e 100644
--- a/packages/triggers/trigger-schedule/package.json
+++ b/packages/triggers/trigger-schedule/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/trigger-schedule",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "Schedule flow trigger for ObjectStack — auto-launches flows on a cron/interval/once schedule via the IJobService (ADR-0018)",
   "main": "dist/index.js",
diff --git a/packages/types/CHANGELOG.md b/packages/types/CHANGELOG.md
index 38b25378a2..2bd3a5ca1b 100644
--- a/packages/types/CHANGELOG.md
+++ b/packages/types/CHANGELOG.md
@@ -1,5 +1,374 @@
 # @objectstack/types
 
+## 17.0.0-rc.4
+
+### Minor Changes
+
+- 28ad90e: feat(types,cloud-connection,lint,cli): ADR-0120 17.x 收尾 —— `isolated` 安装期姿态硬门(D5e)、D5c 重拼写 advisory、成文契约扫荡与三姿态 conformance (#5081)
+
+  ADR-0120 17.x 波的第三块,也是最后一块。前两块已在 main 上:#5212(driver 侧
+  D3+D4 —— `COALESCE(organization_id, '__global__')` 物化、drift 两侧同步、重复预检)
+  与 #5208(spec 词汇 `'organization'` + D5a/D5b lint)。本次补齐三件事:安装期的
+  姿态决策点、剩余的成文契约、以及把「一个 app 包跑遍三种姿态」从假设变成测试。
+
+  **D5e —— 装进 `isolated` 环境时的硬门。** 词汇本身是姿态无关的:作者说的是业务
+  边界(`'organization'` 一个组织一份 / `'global'` 整个安装一份),没有任何索引形状
+  读姿态。唯一的残留在一个方向上:`isolated` 下组织就是**不同客户**,此时 app 业务
+  对象上的 `'global'` 唯一既跨客户过度约束,又变成跨客户的存在性预言机(S10/S14)。
+  维护者裁定这是**硬门而非 advisory**:把带 `'global'` 唯一(非 `sys` 对象)的 app
+  装进 `isolated` 环境会**停下来并逐索引列出**,安装者(通常是 AI agent)要么确认它
+  确实是平台级的,要么改写为 `'organization'`;确认按 ADR-0104 attestation 风格
+  留痕在安装清单里(`InstalledManifestEntry.globalUniqueAttestation` —— 确认了什么、
+  谁确认的、何时、在哪个姿态下问的),**之后不复问**。
+
+  - 停下的安装**什么都不留**:先于 hot-register 和任何 ledger 写入,所以作者改完
+    元数据可以直接重试,不需要先卸载。
+  - 逐索引确认是有牙齿的:`confirmGlobalUniques` 收 `true` 或明确的 id 数组,只确认
+    其中一条仍会在剩下的那条上停住。
+  - 升级引入的**新**约束会被问,老的答案继续算数。
+  - 另一个姿态下给出的确认**不算同意** —— `isolated` 那个问题在 `single` 下从未被
+    问过,所以按「未确认」处理(唯一不会静默放行跨客户约束的方向)。
+  - ⛔ **永不做成启动期告警**(#4884 纪律)。boot 时的 rehydrate 不评估此门;门够不到
+    的两类存量 —— 门禁上线前的安装、装后姿态变更的环境 —— 由 `os doctor` 与
+    `os migrate plan` 的 advisory 形态覆盖。
+
+  判定里有三条是承重的,别「简化」掉:声明索引上的裸 `unique: true` **算**(D1 说它
+  就是 `'global'` 的位置式拼写,排除它等于让整个 17.x 可以靠拼写绕过);字段级
+  `true` **不算**(它是 `'organization'`,永久合法);`sys_`/`base_` 对象**不算**
+  (S5 那批引擎幂等键天然就是平台级的,每次安装都问一遍就是 #4884 的误报类)。
+
+  CLI: `os package install` 新增 `--confirm-global-uniques`,并把 409 渲染成可读的
+  逐条清单而不是一句 "Install failed (409)"。
+
+  **D5c —— 遗留手写组织复合索引的 advisory。** 新规则
+  `unique/legacy-organization-composite`:声明的唯一索引自己列出了组织列
+  (`{ fields: ['name','organization_id'], unique: true }`)—— 这是词汇出现之前手写
+  per-organization 的写法。它读起来像「每组织唯一」,物化出来却是普通复合索引,而
+  SQL UNIQUE 是 NULL-distinct 的:组织列为 NULL 的行上它**什么都不约束**(#5030),
+  在单组织部署上那就是每一行。改写成 `unique: 'organization'`(`fields` 原样保留,
+  driver 会把已列出的组织列**就地**变成 NULL-safe 形式)正是补上这个洞的动作。
+  **永远只是 advisory,永远不自动修**:老拼写永久合法、零强制 drift,而 opt-in 是
+  真实的物理收紧,要走 D4 的 `recreate_index` + 重复预检。
+
+  **D6 —— 成文契约扫荡。** `content/docs/data-modeling/indexing.mdx` 的
+  §Two ways to say "unique" 全节按新词汇重写(含 `os:check` 代码块);
+  `content/docs/protocol/objectql/schema.mdx` 的 §Uniqueness and tenancy 重写为
+  §Uniqueness and scope —— 其中那句「单租户部署不受影响,租户列是常量,复合索引
+  退化为单列索引」是 #5030 **证伪过的原话**,现已替换为 D3 的 NULL-safe 事实;
+  `content/docs/deployment/cli.mdx` 的 `replace_unique_index` / `recreate_index`
+  条目补上 NULL-safe 形状与重复预检;`content/docs/references/**` 经
+  `gen:schema && gen:docs` 再生成,未手改。
+
+  按 ADR-0120 Resolved #2 的非规范性引导(官方示例/脚手架/生成器在新代码中输出
+  显式拼写),`skills/objectstack-data/**` 的索引与校验规则整体扫过:声明索引一律
+  说清 scope,并新增一节完整讲 `'organization'` 的 NULL-safe 语义与「永远不写姿态」。
+  顺带修掉那里长期使用的 `tenant_id` —— 平台的列叫 `organization_id`。
+  `examples/**`、`create-objectstack` 模板与 `os generate` 经核查**根本没有声明任何
+  唯一约束**,故无可扫;这是核查结论,不是遗漏。
+
+  **三姿态 conformance(ADR §Acceptance tests)。** 同一个 fixture app 在
+  `single | group | isolated` 三姿态下启动,逐 S 行用**真实的违规插入**断言 enforcement
+  (S1/S2/S3/S4/S5/S6/S7/S8/S9/S11/S12),并逐姿态捕获物化出的索引键,断言三者
+  **逐字节相同** —— 「没有任何索引形状读姿态」这句话一旦有两者不同就是假的。相同性
+  断言配了一条正向断言(对着期望的键形状),这样「三次都什么都没建」不会读成「一致」。
+  外加 ADR 只要的那一条 transition smoke:在 `single` 下建库、`isolated` 下重新打开,
+  drift op 为零。
+
+  对既有部署的影响:除新增的安装期确认外,本次不改变任何已有物化行为。字段级
+  `unique: true` 一如既往合法。
+
+- 64cd010: fix(runtime,types)!: `/analytics/query` no longer echoes RLS policy field names — the declared-server-fault withhold is shared by both HTTP boundaries (#5811)
+
+  **Observable behaviour change — read this if you read, log, or assert on
+  `error.message` from a dispatcher-plugin route.** An error that **declares a
+  server fault** in the ADR-0112 envelope (`status >= 500` _and_ a non-empty
+  `code`) now leaves `dispatcher-plugin.errorResponseBase` with its message
+  replaced by `"Internal server error"`. It previously reached the caller verbatim
+  unless it happened to _sound_ like a SQL/driver dump. This applies to every route
+  that plugin mounts — `/analytics`, `/packages`, `/i18n`, `/automation`, `/auth`,
+  `/notifications`, `/mcp`, … — not only the one that motivated it. Nothing a
+  machine reads changed: the producer's `code` still arrives in the response
+  (`error.code`, promoted there from `details` by the shared envelope builder,
+  #3842), the status is untouched, and the full original text still goes to the
+  server log and `errorReporter` via `__obsRecordedError`.
+
+  ## What was wrong
+
+  #5367 (maintainer ruling 2026-08-06) made `read-scope-sql.ts`'s ten fail-closed
+  RLS lowering refusals `READ_SCOPE_COMPILE_FAILED` / 500 and taught
+  `POST /analytics/dataset/query` to withhold their message, because those messages
+  name the field names and comparands of an **administrator's** sharing rule:
+
+  ```
+  [read-scope-sql] unsafe field identifier "secret_policy_field" — refusing to
+  build read scope (fail-closed).
+  ```
+
+  The caller never wrote that field name and must not be able to read it out of an
+  error body. But the **sibling** analytics face was never closed.
+  `compileScopedFilterToSql` runs on both `NativeSQLStrategy.applyReadScope` and
+  `ObjectQLStrategy`'s echoed SQL, both of which serve `POST /analytics/query`,
+  which exits through `dispatcher-plugin.errorResponseBase`. That exit's only
+  message guard was `looksLikeInternalErrorLeak` — a heuristic over SQL/driver
+  _phrasing_ — and all eleven read-scope message shapes return `false` from it.
+  Measured at that boundary: **11 of 11 echoed verbatim**, at 500, with the policy
+  content in `error.message`. A real reachable disclosure, not a theoretical one.
+
+  ## What changed
+
+  - **`@objectstack/types` gains `declaresServerFault(err)`**, exported from
+    `error-leak.ts` beside `looksLikeInternalErrorLeak`. The heuristic asks whether
+    a message _sounds_ internal; the declaration asks whether the producer _said
+    so_. `error-leak.ts`'s own file header already states the principle — "do not
+    ship driver internals to clients" is a property of the HTTP boundary, not of
+    one router — and this is the second predicate that principle asks for.
+  - **Both boundaries read it.** `dispatcher-plugin.errorResponseBase` gains the
+    withhold (the fix); `rest-server.ts`'s `/analytics/dataset/query` catch drops
+    its in-line copy of the same test in favour of the shared one. #5808 wrote that
+    rule in-line on purpose — promoting a rule with one consumer is a speculative
+    surface — and this is the second consumer, so it was promoted rather than
+    duplicated (`#3843`/`#3867` paid for the two-implementations shape twice).
+    The REST face's verdict is unchanged in every case: same `status >= 500` plus
+    non-empty `code` test, over the same two fields.
+
+  ## What deliberately did NOT change
+
+  - ⛔ **This is not "withhold every 5xx".** #5667 kept **undeclared** 5xx errors
+    legible on purpose: a bare `Error` from our own code ("no strategy can handle
+    query …") is the operator's own bug report, names nothing tenant-sensitive, and
+    still falls to `looksLikeInternalErrorLeak` alone. A 5xx carrying only half an
+    envelope (a status with no code) is likewise still readable — inventing the
+    withhold for it would be the consumer-side leniency Prime Directive #12 removes.
+  - **4xx is untouched.** `declaresServerFault` requires `status >= 500`, so a
+    deliberate business/validation answer can never be swallowed by it.
+  - **`statusCode` is not accepted as a substitute for `status`.** `status` is the
+    channel ADR-0112 declares; making a disclosure rule depend on which spelling a
+    producer reached for would be the same leniency in a different place.
+  - **The heuristic was not taught to recognise `[read-scope-sql]`.** That would be
+    more prose sniffing — the mechanism #5352/#5367 exist to remove — and would only
+    ever cover the family someone remembered to add.
+
+  Coverage: `analytics-query-read-scope-withhold.test.ts` (runtime) drives six RLS
+  policy shapes end-to-end through a **real** `AnalyticsService` on the real
+  native-SQL path and the real mounted route, asserting the 500, that the whole
+  serialized body contains no policy detail, that `error.code` still carries
+  `READ_SCOPE_COMPILE_FAILED`, and that the full text is still on the
+  `__obsRecordedError` side-channel — plus a positive control and both sides of the
+  declared-vs-undeclared tiering. `error-leak.test.ts` (types) pins the predicate
+  directly, including that all eleven read-scope shapes stay invisible to the
+  heuristic. The REST face's existing `analytics-read-scope-refusal-envelope.test.ts`
+  is green before and after, unchanged, which is the pin on the refactor.
+
+- 02dc076: feat(types,cli,verify)!: 只解析 host app 声明过的包 —— `NODE_PATH` 不再算数,ADR-0093 D5 那道墙从此与启动方式无关 (#4719)
+
+  **问题:契约写下了,但从没被检查过。** `@objectstack/types/node` 的
+  `createHostRequire` 返回一个 CJS `createRequire`,而 CJS 解析认 `NODE_PATH`
+  (`Module.globalPaths`)。pnpm 生成的 bin shim 第一件事就是
+  `export NODE_PATH=<workspace>/node_modules/.pnpm/node_modules`,于是任何被工作区里
+  **任意一个包**传递依赖到的包都能"从 host app 解析成功" —— 跟这个 app 声明了什么毫无关系。
+
+  实测(cloud `apps/objectos-ee`,当时未声明 `@objectstack/organizations`):
+  `pnpm start`(经 shim)boot 成功、插件表里有 `Organizations`、ADR-0093 D5 一声不吭;
+  `node node_modules/@objectstack/cli/bin/run.js serve`(不经 shim)则
+  `✖ FATAL: tenancy posture 'isolated' was requested…` 并 exit 1。同一个 app、同一份
+  `package.json`、同一个 posture,**只因为进程是怎么被拉起来的**,走出两种结果。
+  而 D5 的报错一直在教 operator "declare it in the app's package.json" —— 那正是
+  CLI 从来没检查过的那件事。
+
+  **改法:声明即执行。** 解析前先读 `<hostRoot>/package.json`;只有包名出现在
+  `dependencies` / `devDependencies` / `optionalDependencies` / `peerDependencies`
+  的 **键**里,才去 host 的 `node_modules` 里查它。仅仅"能被解析到"不再算数 ——
+  那正是让契约失效的那个偶然。未声明的包退回到 importing package 自身的解析
+  (ESM,不认 `NODE_PATH`),框架自有的包加载路径不受影响。
+
+  **两种失败从此分开报。** 今天它们都塌成同一条 `MODULE_NOT_FOUND`,补救办法却相反:
+
+  - **未声明** —— 指向"在 app 的 `package.json` 里声明并安装",并说明为什么
+    hoisting / `NODE_PATH` 不被接受;
+  - **声明了但解析不到** —— 明确说这是**安装**问题(`pnpm install`、生产 prune
+    砍掉了它、dist 没构建),别再让人回去重看那份已经写对的 `package.json`。
+
+  分类经新导出的 `hostImportFailureKind(err)` 暴露给调用方;两种错误都仍带
+  `code: 'MODULE_NOT_FOUND'`,`isModuleNotFoundError` 的既有判定不变。
+
+  **BREAKING — 哪类部署会从假绿变红,以及怎么修。**
+
+  1. **靠 hoisting 苟着的部署。** 一个 app 请求了 walled tenancy posture
+     (`OS_TENANCY_POSTURE=group` / `isolated` 或 `OS_MULTI_ORG_ENABLED=1`)、
+     却没在自己的 `package.json` 里声明 `@objectstack/organizations`,过去经 pnpm
+     shim 启动能正常 boot —— 现在会命中 ADR-0093 D5 并 exit 1。
+     **修法:在那个 app 的 `package.json` 里声明该依赖并安装。**
+     这些部署本来就在未声明状态下运行,红的是一直存在的事实,不是新引入的故障:
+     同一个 app 不经 shim 启动今天就已经是 exit 1。
+     (同样适用于 `@objectstack/service-ai` / `@objectstack/service-ai-studio`,以及
+     `bootStack({ multiTenant: true })`、dogfood 的 enterprise 门。)
+
+  2. **`createHostImporter` 的签名变了**,因为它现在需要 host 的**根目录**才能读到
+     那份 manifest,而一个 `NodeRequire` 无法被问出它锚在哪里:
+
+     ```diff
+     - createHostImporter(createHostRequire(hostRoot))
+     + createHostImporter(hostRoot)                     // 省略参数 = process.cwd(),同旧默认
+     ```
+
+     `createHostRequire` 本身保持不变,仍然导出。
+
+  新增导出(`@objectstack/types/node`):`HOST_DECLARATION_FIELDS`、
+  `HostDeclarationField`、`HostDeclaration`、`readHostDeclaration`、
+  `isDeclaredByHost`、`packageNameFromSpecifier`、`HostImportFailureKind`、
+  `HOST_IMPORT_FAILURE_KIND`、`hostImportFailureKind`。
+
+### Patch Changes
+
+- 08f93bc: fix(auth): `organization/create` gates on the authoritative `OS_TENANCY_POSTURE`, not the demoted `OS_MULTI_ORG_ENABLED` (#5233)
+
+  A deployment configured the documented way — `OS_TENANCY_POSTURE=isolated` (or
+  `group`), legacy boolean unset — mounted the entire organization wall and still
+  answered `403 Creating additional organizations is disabled on this deployment.`
+  to `POST /api/v1/auth/organization/create`. Org-less users had no way to create
+  their workspace, so the guided "Create your workspace" path was a dead end.
+
+  ADR-0105 D1 made `OS_TENANCY_POSTURE` the canonical knob and demoted
+  `OS_MULTI_ORG_ENABLED` to a back-compat _input_ of `resolveTenancyPosture()`.
+  Two sites in `AuthManager` kept reading the demoted boolean directly, so both
+  reported "single-org" on a deployment that had asked for a wall and got one:
+
+  - `organizationHooks.beforeCreateOrganization` — the 403 above. It now judges
+    `postureEnforcesWall(resolveTenancyPosture())`, matching the knob `serve.ts`'s
+    own ADR-0093 D5 boot guard keys on. Intent is unchanged (single-org still
+    refuses); only the knob is corrected.
+  - `/auth/config`'s `features.multiOrgEnabled` — its no-tenancy-service fallback
+    read the same boolean. It now falls back to the resolved posture, so a lean
+    embedding advertises the capability its own gate allows.
+
+  **No configuration change is needed anywhere.** Deployments that set only
+  `OS_MULTI_ORG_ENABLED=true` keep working unchanged — `resolveTenancyPosture()`
+  falls back to it — and the `OS_TENANCY_POSTURE=isolated` + `OS_MULTI_ORG_ENABLED=true`
+  workaround people used to unblock themselves stays valid. Deployments that set
+  only `OS_TENANCY_POSTURE` can now drop the redundant boolean.
+
+  `resolveMultiOrgEnabled()`'s doc comment in `@objectstack/types` — which still
+  instructed "the auth manager's `/auth/config` feature flag and org-create guard
+  … MUST call this", written before the demotion — now says the opposite: ask the
+  posture, and never gate on this boolean. Its behaviour is unchanged.
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [d4e0809]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [978fed2]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [2e284b2]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [947d4f9]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [37e38d1]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [c52e608]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [85d95e7]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [d9971d3]
+- Updated dependencies [abeb375]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [7f1a635]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [b508244]
+- Updated dependencies [594508e]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [26e1029]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [7d27da0]
+- Updated dependencies [089767f]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [7b005b4]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [c5a5996]
+- Updated dependencies [ae490ef]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [c183a12]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+  - @objectstack/spec@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Minor Changes
diff --git a/packages/types/package.json b/packages/types/package.json
index ced7e44b99..03e695ee6f 100644
--- a/packages/types/package.json
+++ b/packages/types/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/types",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "Shared interfaces describing the ObjectStack Runtime environment",
   "main": "dist/index.js",
diff --git a/packages/verify/CHANGELOG.md b/packages/verify/CHANGELOG.md
index 467fec5a35..1e4942af72 100644
--- a/packages/verify/CHANGELOG.md
+++ b/packages/verify/CHANGELOG.md
@@ -1,5 +1,390 @@
 # @objectstack/verify
 
+## 17.0.0-rc.4
+
+### Minor Changes
+
+- 02dc076: feat(types,cli,verify)!: 只解析 host app 声明过的包 —— `NODE_PATH` 不再算数,ADR-0093 D5 那道墙从此与启动方式无关 (#4719)
+
+  **问题:契约写下了,但从没被检查过。** `@objectstack/types/node` 的
+  `createHostRequire` 返回一个 CJS `createRequire`,而 CJS 解析认 `NODE_PATH`
+  (`Module.globalPaths`)。pnpm 生成的 bin shim 第一件事就是
+  `export NODE_PATH=<workspace>/node_modules/.pnpm/node_modules`,于是任何被工作区里
+  **任意一个包**传递依赖到的包都能"从 host app 解析成功" —— 跟这个 app 声明了什么毫无关系。
+
+  实测(cloud `apps/objectos-ee`,当时未声明 `@objectstack/organizations`):
+  `pnpm start`(经 shim)boot 成功、插件表里有 `Organizations`、ADR-0093 D5 一声不吭;
+  `node node_modules/@objectstack/cli/bin/run.js serve`(不经 shim)则
+  `✖ FATAL: tenancy posture 'isolated' was requested…` 并 exit 1。同一个 app、同一份
+  `package.json`、同一个 posture,**只因为进程是怎么被拉起来的**,走出两种结果。
+  而 D5 的报错一直在教 operator "declare it in the app's package.json" —— 那正是
+  CLI 从来没检查过的那件事。
+
+  **改法:声明即执行。** 解析前先读 `<hostRoot>/package.json`;只有包名出现在
+  `dependencies` / `devDependencies` / `optionalDependencies` / `peerDependencies`
+  的 **键**里,才去 host 的 `node_modules` 里查它。仅仅"能被解析到"不再算数 ——
+  那正是让契约失效的那个偶然。未声明的包退回到 importing package 自身的解析
+  (ESM,不认 `NODE_PATH`),框架自有的包加载路径不受影响。
+
+  **两种失败从此分开报。** 今天它们都塌成同一条 `MODULE_NOT_FOUND`,补救办法却相反:
+
+  - **未声明** —— 指向"在 app 的 `package.json` 里声明并安装",并说明为什么
+    hoisting / `NODE_PATH` 不被接受;
+  - **声明了但解析不到** —— 明确说这是**安装**问题(`pnpm install`、生产 prune
+    砍掉了它、dist 没构建),别再让人回去重看那份已经写对的 `package.json`。
+
+  分类经新导出的 `hostImportFailureKind(err)` 暴露给调用方;两种错误都仍带
+  `code: 'MODULE_NOT_FOUND'`,`isModuleNotFoundError` 的既有判定不变。
+
+  **BREAKING — 哪类部署会从假绿变红,以及怎么修。**
+
+  1. **靠 hoisting 苟着的部署。** 一个 app 请求了 walled tenancy posture
+     (`OS_TENANCY_POSTURE=group` / `isolated` 或 `OS_MULTI_ORG_ENABLED=1`)、
+     却没在自己的 `package.json` 里声明 `@objectstack/organizations`,过去经 pnpm
+     shim 启动能正常 boot —— 现在会命中 ADR-0093 D5 并 exit 1。
+     **修法:在那个 app 的 `package.json` 里声明该依赖并安装。**
+     这些部署本来就在未声明状态下运行,红的是一直存在的事实,不是新引入的故障:
+     同一个 app 不经 shim 启动今天就已经是 exit 1。
+     (同样适用于 `@objectstack/service-ai` / `@objectstack/service-ai-studio`,以及
+     `bootStack({ multiTenant: true })`、dogfood 的 enterprise 门。)
+
+  2. **`createHostImporter` 的签名变了**,因为它现在需要 host 的**根目录**才能读到
+     那份 manifest,而一个 `NodeRequire` 无法被问出它锚在哪里:
+
+     ```diff
+     - createHostImporter(createHostRequire(hostRoot))
+     + createHostImporter(hostRoot)                     // 省略参数 = process.cwd(),同旧默认
+     ```
+
+     `createHostRequire` 本身保持不变,仍然导出。
+
+  新增导出(`@objectstack/types/node`):`HOST_DECLARATION_FIELDS`、
+  `HostDeclarationField`、`HostDeclaration`、`readHostDeclaration`、
+  `isDeclaredByHost`、`packageNameFromSpecifier`、`HostImportFailureKind`、
+  `HOST_IMPORT_FAILURE_KIND`、`hostImportFailureKind`。
+
+- de113a4: BREAKING(auth): `organization/create` 改判**实际生效的** tenancy posture —— 没有组织墙的部署不再能创建组织 (#5261)
+
+  `POST /api/v1/auth/organization/create` 的闸门此前判的是操作者**请求的** posture
+  (`postureEnforcesWall(resolveTenancyPosture())`,一次纯 env 读)。现在判 `tenancy` 服务给出的
+  **生效** posture —— `tenancy?.posture ?? resolveTenancyPosture()`,与 `/auth/config` 的
+  `features.multiOrgEnabled` 是**同一次求值**。
+
+  ## 为什么
+
+  两个站点此前只在一种形状下分叉,而那种形状恰恰是最不该放行的一种 —— ADR-0093 D5 **降级态**:
+  请求了 `isolated`/`group`,但企业包 `@objectstack/organizations` 缺席,于是 `tenancy.posture`
+  解析为 `single` 且 `degraded=true`。此时:
+
+  - 闸门读「请求」→ **放行**;
+  - `/auth/config` 读「生效」→ `multiOrgEnabled=false`,console 把「创建组织」入口**藏起来**。
+
+  结果是 UI 没有按钮而 API 打得通,并且建出来的每一个组织都是**没有任何引擎强制的租户边界** ——
+  声明了但没强制,ADR-0049 最讨厌的那一类,只不过发生在部署层。改判生效 posture 之后两者同解、
+  永不分叉:**没有墙,就没有组织**,无论这个部署是从未要过墙,还是要了没拿到。
+
+  ## 破坏性影响(有意为之)
+
+  **没有安装企业包 `@objectstack/organizations` 的部署将完全无法创建组织**,任何 env 组合都不行 ——
+  `OS_TENANCY_POSTURE=isolated`、`OS_MULTI_ORG_ENABLED=true`、两个一起设,都不再能把闸门说通。
+  这是一次实打实的能力收缩,不是 knob 纠正,所以搭 v17 主版本车。
+
+  | 部署形状                                          | 改前   | 改后          |
+  | ------------------------------------------------- | ------ | ------------- |
+  | 有企业包,posture `isolated` / `group`(墙真的立着) | 200    | **200**(不变) |
+  | **请求了墙但企业包缺席(D5 降级态)**               | 200    | **403** ⚠️    |
+  | `single` / 两个 knob 都不设                       | 403    | 403(不变)     |
+  | 未注册 `tenancy` 服务的精简嵌入(回落 env 解析)    | 按 env | 按 env(不变)  |
+
+  `serve.ts` 本来就在降级态**默认拒绝启动**(要 `OS_ALLOW_DEGRADED_TENANCY=1` 才走),所以这条收缩
+  命中的是一个已经需要显式选择才能到达的形状:从此那里的 org-create 路由也一并拒绝,而不是半通不通。
+  cloud 控制面与任何装了企业包的部署不受影响。
+
+  **迁移**:需要多组织能力的部署安装并声明 `@objectstack/organizations`(ADR-0081 D2)。仅靠 env
+  声明一个墙、而没有实现它的运行时,不再被当作多组织部署对待。
+
+  ## `@objectstack/verify`(minor,新增)
+
+  `BootOptions.multiTenant` 增加 `'posture-only'` 取值:注册一个内置的 `org-scoping` 服务替身,
+  让 `tenancy` 服务解析出真实、**非降级**的 `isolated` posture,从而打开受 posture 把守的路由 ——
+  供那些「组织墙是**前置条件**而非被测对象」的 fixture 使用(#3624 的 `org-create-default-team`
+  dogfood 就是为它而建:那条回归此前靠「boot 后翻 env、闸门 live 读」开路,本次收缩把这个绕法关死了)。
+
+  ⛔ 它**不做任何租户隔离**:不 stamp `organization_id`,不 scope 任何查询 —— 它让部署的
+  **posture** 为真,不是让**墙**为真。跨租户隔离的唯一诚实证明仍然是 `multiTenant: true` +
+  真实的企业包,这也是那些 gate 在本仓继续 skip 而不是假装通过的原因。
+
+### Patch Changes
+
+- Updated dependencies [9fe9c1d]
+- Updated dependencies [da5d1b4]
+- Updated dependencies [d4e0809]
+- Updated dependencies [739f496]
+- Updated dependencies [f724f69]
+- Updated dependencies [28ad90e]
+- Updated dependencies [f8644c7]
+- Updated dependencies [306ca50]
+- Updated dependencies [c637387]
+- Updated dependencies [c113690]
+- Updated dependencies [705efeb]
+- Updated dependencies [978fed2]
+- Updated dependencies [c36abfe]
+- Updated dependencies [9ecdca9]
+- Updated dependencies [cfc293f]
+- Updated dependencies [de70b42]
+- Updated dependencies [1792384]
+- Updated dependencies [2f6516e]
+- Updated dependencies [e6b1bb0]
+- Updated dependencies [a7b854f]
+- Updated dependencies [f56ebea]
+- Updated dependencies [64cd010]
+- Updated dependencies [f522e95]
+- Updated dependencies [fb3d99b]
+- Updated dependencies [628b028]
+- Updated dependencies [b857356]
+- Updated dependencies [fce4c73]
+- Updated dependencies [f6385c7]
+- Updated dependencies [cdfbee2]
+- Updated dependencies [29c6c9d]
+- Updated dependencies [d21c001]
+- Updated dependencies [f1cc3a3]
+- Updated dependencies [ddc2527]
+- Updated dependencies [553a47f]
+- Updated dependencies [7a40b7a]
+- Updated dependencies [7cf1531]
+- Updated dependencies [586d6f7]
+- Updated dependencies [9f747ee]
+- Updated dependencies [2d14b35]
+- Updated dependencies [a3a884d]
+- Updated dependencies [cfed092]
+- Updated dependencies [c497d26]
+- Updated dependencies [bbdbf28]
+- Updated dependencies [93929c2]
+- Updated dependencies [2e284b2]
+- Updated dependencies [3905c00]
+- Updated dependencies [4335497]
+- Updated dependencies [43ca399]
+- Updated dependencies [1b49eaf]
+- Updated dependencies [0161c7f]
+- Updated dependencies [e900015]
+- Updated dependencies [b5bdf48]
+- Updated dependencies [a019e52]
+- Updated dependencies [02a8256]
+- Updated dependencies [64fc6d5]
+- Updated dependencies [b746aa0]
+- Updated dependencies [846ed1f]
+- Updated dependencies [947d4f9]
+- Updated dependencies [d8f65fe]
+- Updated dependencies [58ffcab]
+- Updated dependencies [eaaf03c]
+- Updated dependencies [d17df80]
+- Updated dependencies [7d0e7b5]
+- Updated dependencies [6513c17]
+- Updated dependencies [1f0e7cb]
+- Updated dependencies [8dbd2a8]
+- Updated dependencies [99d7a93]
+- Updated dependencies [c142ced]
+- Updated dependencies [eda599e]
+- Updated dependencies [f205c32]
+- Updated dependencies [7bf3d1c]
+- Updated dependencies [9ce0ca9]
+- Updated dependencies [db9c331]
+- Updated dependencies [c001422]
+- Updated dependencies [77022a9]
+- Updated dependencies [217b791]
+- Updated dependencies [fd8521f]
+- Updated dependencies [52760bf]
+- Updated dependencies [5543020]
+- Updated dependencies [880d343]
+- Updated dependencies [6e82972]
+- Updated dependencies [4615a18]
+- Updated dependencies [2b63a00]
+- Updated dependencies [18b8eaa]
+- Updated dependencies [7f62706]
+- Updated dependencies [667fa44]
+- Updated dependencies [9c4f174]
+- Updated dependencies [37e38d1]
+- Updated dependencies [cc5b048]
+- Updated dependencies [78adc2e]
+- Updated dependencies [81e2744]
+- Updated dependencies [277eb36]
+- Updated dependencies [41e605e]
+- Updated dependencies [2649ccb]
+- Updated dependencies [1eb13a0]
+- Updated dependencies [a70cd0a]
+- Updated dependencies [c52e608]
+- Updated dependencies [96d3d4d]
+- Updated dependencies [afa6aa5]
+- Updated dependencies [afb83d3]
+- Updated dependencies [4022b78]
+- Updated dependencies [4dfd002]
+- Updated dependencies [77be690]
+- Updated dependencies [811c30c]
+- Updated dependencies [b49ccfd]
+- Updated dependencies [c7406b0]
+- Updated dependencies [85d95e7]
+- Updated dependencies [8108787]
+- Updated dependencies [168f60f]
+- Updated dependencies [244ca86]
+- Updated dependencies [546ab3c]
+- Updated dependencies [0b51bb6]
+- Updated dependencies [08f93bc]
+- Updated dependencies [d9971d3]
+- Updated dependencies [d97f2a2]
+- Updated dependencies [d9cac60]
+- Updated dependencies [eb3e650]
+- Updated dependencies [abeb375]
+- Updated dependencies [dfa8bad]
+- Updated dependencies [ef4efa8]
+- Updated dependencies [cbb6a5c]
+- Updated dependencies [290d944]
+- Updated dependencies [02dc076]
+- Updated dependencies [795b6e1]
+- Updated dependencies [175d789]
+- Updated dependencies [55dbbba]
+- Updated dependencies [72c3c86]
+- Updated dependencies [88a6bed]
+- Updated dependencies [a6b3ee7]
+- Updated dependencies [7f1a635]
+- Updated dependencies [e98fb14]
+- Updated dependencies [5d3ced9]
+- Updated dependencies [9fa6bab]
+- Updated dependencies [0f2fdcd]
+- Updated dependencies [8ffa8b9]
+- Updated dependencies [674ac99]
+- Updated dependencies [1b9a53b]
+- Updated dependencies [61dc08e]
+- Updated dependencies [8dcf607]
+- Updated dependencies [b691ba9]
+- Updated dependencies [1eadac0]
+- Updated dependencies [7c2f7dd]
+- Updated dependencies [9b26699]
+- Updated dependencies [502564d]
+- Updated dependencies [471839d]
+- Updated dependencies [46365ab]
+- Updated dependencies [b508244]
+- Updated dependencies [8597a7d]
+- Updated dependencies [594508e]
+- Updated dependencies [ff39e63]
+- Updated dependencies [1c625ca]
+- Updated dependencies [71f205d]
+- Updated dependencies [414395b]
+- Updated dependencies [c5adfe1]
+- Updated dependencies [26e1029]
+- Updated dependencies [1cae606]
+- Updated dependencies [4addd9d]
+- Updated dependencies [108ba8d]
+- Updated dependencies [b9cc17d]
+- Updated dependencies [b4ad984]
+- Updated dependencies [a9f32df]
+- Updated dependencies [75f82f3]
+- Updated dependencies [aeb9b27]
+- Updated dependencies [1203bb2]
+- Updated dependencies [7d27da0]
+- Updated dependencies [de113a4]
+- Updated dependencies [caf144a]
+- Updated dependencies [db8c285]
+- Updated dependencies [0d24078]
+- Updated dependencies [089767f]
+- Updated dependencies [5b8f95b]
+- Updated dependencies [dadf542]
+- Updated dependencies [2ddba89]
+- Updated dependencies [e4c8b6c]
+- Updated dependencies [acb10f6]
+- Updated dependencies [ef7845a]
+- Updated dependencies [1c3da1f]
+- Updated dependencies [a34fd2e]
+- Updated dependencies [2cca98b]
+- Updated dependencies [07f1822]
+- Updated dependencies [37a8f2b]
+- Updated dependencies [441d79f]
+- Updated dependencies [7f955e5]
+- Updated dependencies [889ae47]
+- Updated dependencies [4f4c3fb]
+- Updated dependencies [dc6abfd]
+- Updated dependencies [39396bd]
+- Updated dependencies [577cd27]
+- Updated dependencies [5897552]
+- Updated dependencies [91ec1ea]
+- Updated dependencies [2d25303]
+- Updated dependencies [7adc841]
+- Updated dependencies [4845f85]
+- Updated dependencies [bf1edef]
+- Updated dependencies [7b005b4]
+- Updated dependencies [0cd08d5]
+- Updated dependencies [94f7b6a]
+- Updated dependencies [5c94f83]
+- Updated dependencies [73e576f]
+- Updated dependencies [2680cd3]
+- Updated dependencies [c5a5996]
+- Updated dependencies [cba7454]
+- Updated dependencies [b40f81c]
+- Updated dependencies [82a06af]
+- Updated dependencies [6e66cbe]
+- Updated dependencies [f226605]
+- Updated dependencies [c272e48]
+- Updated dependencies [db2ea82]
+- Updated dependencies [51a587d]
+- Updated dependencies [ae490ef]
+- Updated dependencies [1216dcc]
+- Updated dependencies [9c90ea0]
+- Updated dependencies [41c3b48]
+- Updated dependencies [f61c8cf]
+- Updated dependencies [e3ef52b]
+- Updated dependencies [07f1822]
+- Updated dependencies [04fab5e]
+- Updated dependencies [ef8b1ff]
+- Updated dependencies [efedd28]
+- Updated dependencies [5278e11]
+- Updated dependencies [23dba62]
+- Updated dependencies [ba98e26]
+- Updated dependencies [d56bcdb]
+- Updated dependencies [f104bab]
+- Updated dependencies [fc5f536]
+- Updated dependencies [f8cfbb4]
+- Updated dependencies [5aaa6fc]
+- Updated dependencies [dca5bd3]
+- Updated dependencies [488b66c]
+- Updated dependencies [c89d18c]
+- Updated dependencies [aac90a5]
+- Updated dependencies [1e6ab15]
+- Updated dependencies [c87ef70]
+- Updated dependencies [3cb0618]
+- Updated dependencies [32a0874]
+- Updated dependencies [7055c22]
+- Updated dependencies [785a748]
+- Updated dependencies [3af0354]
+- Updated dependencies [866ff16]
+- Updated dependencies [5a85e67]
+- Updated dependencies [90fa077]
+- Updated dependencies [946a131]
+- Updated dependencies [909895d]
+- Updated dependencies [c183a12]
+- Updated dependencies [69a89ce]
+- Updated dependencies [8064b07]
+- Updated dependencies [4a56dbd]
+- Updated dependencies [06df4fa]
+- Updated dependencies [c42a19a]
+- Updated dependencies [f0d98e1]
+- Updated dependencies [229d29e]
+- Updated dependencies [b508244]
+- Updated dependencies [2b52bc8]
+  - @objectstack/spec@17.0.0-rc.4
+  - @objectstack/runtime@17.0.0-rc.4
+  - @objectstack/types@17.0.0-rc.4
+  - @objectstack/service-analytics@17.0.0-rc.4
+  - @objectstack/rest@17.0.0-rc.4
+  - @objectstack/core@17.0.0-rc.4
+  - @objectstack/plugin-hono-server@17.0.0-rc.4
+  - @objectstack/platform-objects@17.0.0-rc.4
+  - @objectstack/plugin-auth@17.0.0-rc.4
+  - @objectstack/service-settings@17.0.0-rc.4
+  - @objectstack/objectql@17.0.0-rc.4
+  - @objectstack/service-automation@17.0.0-rc.4
+  - @objectstack/plugin-security@17.0.0-rc.4
+  - @objectstack/service-datasource@17.0.0-rc.4
+  - @objectstack/plugin-sharing@17.0.0-rc.4
+
 ## 17.0.0-rc.2
 
 ### Minor Changes
diff --git a/packages/verify/package.json b/packages/verify/package.json
index a3c9413ed1..0d74ed845e 100644
--- a/packages/verify/package.json
+++ b/packages/verify/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@objectstack/verify",
-  "version": "17.0.0-rc.3",
+  "version": "17.0.0-rc.4",
   "license": "Apache-2.0",
   "description": "Boot any ObjectStack app in-process and verify it through the real HTTP stack — auto-derived CRUD round-trip fidelity plus the cross-owner RLS invariant. Catches runtime regressions that static checks miss.",
   "type": "module",