Merge remote-tracking branch 'origin/main' into claude/issue-4391-crypto-hash-retire

# Conflicts:
#	docs/protocol-upgrade-guide.md
#	packages/spec/spec-changes.json
#	packages/spec/src/migrations/registry.ts

Author: claude

.changeset/analytics-empty-group-fill-compare-seam.md

@@ -0,0 +1,50 @@
+---
+"@objectstack/service-analytics": minor
+---
+
+fix(service-analytics): a measure a query never reported reads 0 for a count/sum on every merge seam (#4708)
+
+A dataset measure carrying its own `filter` runs as a separate grouped
+sub-query and is merged back onto the selected dimensions. A `GROUP BY` over a
+filtered row set emits **no group at all** for a dimension value the filter
+excludes entirely, so the measure comes back **absent**, not `0` — and
+`computeDerived` treats an absent operand as unknowable, so every ratio over it
+goes null too. The cell then renders blank, which is visually identical to "no
+data for this row" and means the opposite.
+
+The bias runs the worst possible way: the rows that blank are the ones whose
+numerator matched nothing — the **worst-performing rows**. A `lead_source` that
+won nothing rendered as "no data" while one that won everything rendered fine.
+
+The empty-group value is now filled **by aggregate kind** into every measure
+column the assembled grid lists but no query reported:
+
+| aggregate | over an excluded group | why |
+|:---|:---|:---|
+| `count`, `count_distinct` | `0` | "how many rows matched" has an exact answer when the answer is none |
+| `sum` | `0` | the identity element of the empty set |
+| `avg`, `min`, `max` | stays `null` | genuinely undefined — there is nothing to average |
+
+Filling all five with `0` would trade this lie for its mirror image, reporting a
+measurement nobody made, so the kinds are judged separately (via
+`emptyGroupValueFor`, shared with the authoring-side coherence checks).
+
+**Only cells are filled, never rows.** A dimension value no query reported at
+all has genuinely no data and stays out of the grid.
+
+**What changes beyond the measure-scoped seam.** The fill previously ran before
+the `compareTo` merge, and that merge *appends* a row for every bucket the
+PREVIOUS window had and this one does not. Every base measure on those rows —
+including unfiltered ones — was absent, so a lead source that sold last month
+and nothing this month rendered as "no data" instead of `0`: the same worst-row
+bias, one merge later. The fill now runs after every merge and covers all base
+measures plus their `<measure>__compare` columns.
+
+Widgets that worked around this with `?? 0` in the consumer or a `coalesce` in
+the measure can drop it; the coercion belongs in the executor, which is the only
+layer that knows which aggregate produced the gap.
+
+**New export.** `fillEmptyGroups(rows, columnAggregates)` is exported from the
+package root beside `mergeByDimensions`, so a host assembling a grid outside
+`DatasetExecutor` can apply the same aggregate-kind rule rather than
+reimplementing it — which is what makes this a `minor` rather than a `patch`.

.changeset/approval-record-lock-predicate-updates.md

@@ -0,0 +1,57 @@
+---
+"@objectstack/plugin-approvals": patch
+---
+
+fix(approvals): the record lock now holds for predicate (`multi`) updates (#4778)
+
+The ADR-0019 record lock — "while a record has a pending `sys_approval_request`,
+block edits to it" — was enforced only for updates that reach the hook with an
+`input.id`. The engine extracts that id from a **scalar** `where.id` alone; an
+operator object (`{ $in: [...] }`) or any other predicate is a multi-row write
+that routes to `updateMany` and arrives with no id. The hook opened with
+`if (!id) return`, so it read *"no row was resolved"* as *"there is nothing to
+authorize"* when the truth was *"nothing was ever queried"*.
+
+Rewriting the very same edit as `multi: true` therefore walked straight past the
+lock:
+
+```ts
+// rec_1 carries a pending approval, lockRecord is not disabled
+await ql.update('crm_opportunity', { amount: 999 }, { where: { id: 'rec_1' } });                       // RECORD_LOCKED
+await ql.update('crm_opportunity', { amount: 999 }, { where: { id: { $in: ['rec_1'] } }, multi: true }); // went through
+await ql.update('crm_opportunity', { amount: 999 }, { where: { name: 'x' }, multi: true });              // went through
+```
+
+No privilege was needed for that bypass — not an `admin` role, not `isSystem`,
+not `lockRecord: false`, not a whitelisted `approvalStatusField`. Every caller
+shape that can spell a predicate (SDK, ObjectQL, a flow's `update_record`) could
+produce it. It is the same fail-open reasoning fixed for `sys_attachment`
+(#4757) and `sys_comment` (#4630), in the one place where it needed no
+privilege at all.
+
+**The hook now resolves the rows a write touches before deciding.** By-id writes
+are unchanged (the driver writes by primary key, so the rest of `where` must not
+narrow the verdict). A predicate write is decided by intersecting the caller's
+predicate with the records that are actually locked — which is also what keeps
+it cheap: the query is bounded by the object's **pending approvals**, never by
+the update's match set, so a mass update of 50 000 unlocked rows costs one
+bookkeeping probe and is allowed. An unscoped `multi` update over the whole
+table reaches every locked row of the object and is refused while any is held.
+
+**Fail-closed, both ways.** Past 1 000 locked records — the bound the attachment
+and comment guards use — or if the intersection query fails, the write is
+refused rather than allowed: the lock could not prove the write misses a locked
+row. The approvals bookkeeping being unreadable at all stays the one fail-open,
+as before: this hook is global over every object, so a kernel without
+`sys_approval_request` would otherwise refuse every update in the deployment.
+Both the bookkeeping and the match-set resolution are read under a **system**
+context — a guard's own input must never be narrowed by the caller's
+visibility, since a locked row you cannot read is still a row you may not write.
+
+**Every exemption moved with the guard**, which is the other way this class of
+fix goes wrong — a guard extended to more rows that carries only its deny rules
+turns a fail-open into a false-positive. `isSystem`, the `admin` override, the
+`approvalStatusField` status mirror, `lockRecord: false` and the owning run's
+`flowRunId` (#3456 / #3712) all decide a predicate write exactly as they decide
+a by-id write, each pinned by tests on both predicate shapes. Refusals now name
+the record and object that are locked.

.changeset/check-i18n-fails-on-undeclared-authoring-key.md

@@ -0,0 +1,45 @@
+---
+---
+
+chore(devx): `pnpm check:i18n` now FAILS on an undeclared authoring key, not just on bundle drift
+
+Releases nothing — the change is confined to `scripts/check-i18n-bundles.mjs` and
+the root `check:i18n` script. No package source, no published behaviour, and
+deliberately **not** the `os i18n extract` exit code (that would write an internal
+hygiene rule into the public CLI contract).
+
+#4736 cleaned nine `scripts/i18n-extract.config.ts` files that all opened their
+`defineStack({ … })` with the same undeclared `name:` key. Nine, because the same
+mistake was copied from the first one — and nothing stopped any of them. The
+#4167 unknown-authoring-key lint *saw* every single one: it printed
+`stack.name: 'name' is not a declared stack key, so its value is dropped at load`
+on stderr, once per package, on every run. But the CLI exited 0 and the gate only
+judged bundle drift, so those nine warnings appeared inside a **fully green**
+`check:i18n` and were read as noise nine times. A warning that nine authors
+filtered out is not a control; #4736 cleaned the symptom, this closes the hole.
+
+**What changed.** The gate now reads the extractor's **stderr** — which it
+previously let flow straight through to the terminal, seen by nobody and judged by
+nothing — and fails on the unknown-authoring-key signature. Coverage needs no
+manifest: `findConfigs` walks `packages/`, so the tenth config is gated the day it
+lands.
+
+**The two verdicts stay separate.** Bundle drift keeps its own section and its own
+remedy (`--write`); the new class gets its own, naming the package, the config
+path, the key, and the consequence that matters — *the value is dropped at load,
+so whatever it was meant to configure is not in effect and never was*.
+Regenerating bundles does not fix it, and the message says so.
+
+**The gate is proven able to go red**, not merely observed green — the failure
+mode of `check:react-declaration-parity` (#4690), which exited 0 with nothing to
+check. Two proofs: `node scripts/check-i18n-bundles.mjs --self-test` (now wired
+into `check:i18n`, ahead of the real run) drives both classifiers over recorded
+CLI output, including a case asserting neither verdict matches the other's output;
+and the gate was run against the nine configs restored from `ffab8033b^`, the
+commit before #4803 deleted the keys, where it reports all nine and exits 1.
+
+Fixing an offending config means deleting the key at the producer. If a key is
+genuinely wanted it gets declared in `packages/spec` deliberately — not
+accommodated by a consumer-side fallback, and not silenced by making
+`ObjectStackDefinitionSchema` strict (which would mute the lint itself; see
+`metadata-authoring-lint.ts`).

.changeset/database-loader-ddl-failure-loud.md

@@ -0,0 +1,40 @@
+---
+"@objectstack/metadata": patch
+---
+
+fix(metadata): `sys_metadata` 的 DDL 失败不再被静默吞掉 —— 只有「表已存在」这一种原因可以静音 (#4728)
+
+`DatabaseLoader.ensureSchema()` 过去用一个空 `catch` 吞掉 **全部** DDL 失败,并且照样把
+`schemaReady` 置为 `true`:
+
+```ts
+} catch {
+  // If syncSchema fails (e.g. table already exists), mark ready and continue
+  this.schemaReady = true;
+}
+```
+
+注释里的免责理由只覆盖了失败原因中最良性的一种,却用它为**所有**原因开脱。真实的失败
+(权限不足、数据源根本没连上、列类型冲突)之后,表或新列压根不存在,而进程的状态与成功
+路径**逐字节相同**,启动日志里一行痕迹都没有 —— 这正是 #4420 的形态:声称已持久化、实
+际没落盘、系统看起来完全健康。#4632 把它定成规则(AGENTS.md → "Degradation log levels"),
+机械检查 `pnpm check:durability-log-level` 已经能发现这一处。
+
+现在按**错误类型**判别,而不是按注释里的乐观假设:
+
+- **良性的「已存在」**(SQLite 的 `table … already exists` / `duplicate column name`、
+  Postgres 的 SQLSTATE `42P07`/`42701`/`42710`、MySQL 的 `ER_TABLE_EXISTS_ERROR` 等及其
+  `errno`,并跟随 `cause` 链)—— 表确实已就绪,当作 no-op 静默通过,并照常执行后续的
+  `project_id → environment_id` 迁移与 ADR-0005 索引。
+- **其余一切失败** —— 以 `console.error` 上报,文案同时说清**后果**(`sys_metadata` 的表/
+  列未创建,后续每一次元数据写入都会报错、或在宽松驱动上悄悄丢列,而服务器仍报告健康)
+  与**修复动作**(修掉下面那条驱动/数据源错误后重启)。只说**一次**,不是每次写入都刷屏。
+- `schemaReady` **不再**在真实失败后置 `true`。启动依旧不被阻断(该方法不抛),但 loader
+  不再声称一个它并不具备的就绪状态,下一次元数据操作会重试 —— 数据源只是还在连接这类瞬
+  时故障因此可以自愈,恢复时补一条 `info`。
+
+`ensureHistorySchema()` 按同一规则对齐:良性「已存在」不再每次写入都打一条 `error`(过度
+使用 `error` 是镜像失败),真实失败则同样只响亮一次并保持重试。
+
+无 API / schema 变更;新增内部工具 `isSchemaAlreadyExistsError()`(未从包入口导出)。
+`scripts/durability-degradation.baseline.json` 中指向本单的条目随之删除(该文件 shrink-only)。

.changeset/host-app-resolver-shared.md

@@ -0,0 +1,48 @@
+---
+"@objectstack/types": minor
+"@objectstack/verify": minor
+"@objectstack/cli": patch
+---
+
+fix(verify): resolve the enterprise organizations package from the HOST APP (#4700)
+
+`bootStack(app, { multiTenant: true })` — and therefore `objectstack verify
+--multi-tenant` — could never load `@objectstack/organizations`. Node ESM
+resolves a bare `import()` against the **importer's own realpath**, which for
+`packages/verify` is inside the framework workspace, while the enterprise
+package is cloud-private and only ever lives in the verified app's
+`node_modules`. Every real host app fell into the catch and was told to
+"Install/link it in this workspace" — about a package it had already installed.
+Same defect class as cloud#1013, which fixed `objectstack serve`; #4699 fixed
+that one call site and this issue tracked the two the sweep left behind.
+
+**New: `@objectstack/types/node`.** The host-app resolver (`createHostRequire` /
+`createHostImporter`) moved out of `packages/cli/src/utils/import-from-host.ts`
+— where `@objectstack/verify` and the dogfood suite could not import it without
+inverting the dependency direction — into a **node-only subpath export** of
+`@objectstack/types`. One behaviour, one source; the CLI now consumes it and its
+private copy is deleted.
+
+It is a subpath and **not** the root export because `@objectstack/types` is a
+dependency of `@objectstack/hono` ("edge-compatible REST API server for
+Cloudflare Workers, Deno, Bun, and Node") and of the plugin layer a `LiteKernel`
+boots on Workers. The root entry reaches zero `node:` builtins, and a Workers
+bundle breaks on `node:module` even when nothing calls it. `tsup` emits the two
+entries as separate self-contained bundles (`splitting: false`), and a test
+walks the root's import graph and fails on the first reachable `node:`
+specifier, so the isolation is enforced rather than merely intended. Same
+arrangement `@objectstack/metadata` already ships for its `./node` subpath.
+
+**New: `BootOptions.hostRoot`** (optional, defaults to `process.cwd()`) names
+the app whose `node_modules` supplies those optional packages — for a harness
+booting an app that is not the working directory.
+
+**The dogfood multi-org gates had never run.** Two suites probed availability
+with the same bare `import()` and so were **constant-false** — not "false
+because absent" but false by construction, in every environment including the
+cloud CI whose comment claimed it ran them. The #1994 cross-tenant RLS proof and
+the attachments cross-tenant isolation block had therefore never executed while
+the suite reported green (Prime Directive #10, test-suite edition). They now
+resolve like the runtime does, and `OS_TEST_MULTI_ORG_ENABLED=1` declares that a
+run is expected to ship the package — turning a silent skip into a loud failure,
+so a run can no longer pass by quietly not running the gates it exists for.

.changeset/http-protocol-discovery-two-shapes.md

@@ -0,0 +1,4 @@
+---
+---
+
+docs(protocol): `protocol/kernel/http-protocol` 的 API Discovery 一节拆成两段式 —— `@objectstack/rest` 服务的 `/api/v1`(与 `/api/v1/discovery`)与 dispatcher 服务的 `/.well-known/objectstack` 各给一份真实响应形状,不再共用一份混合示例。Docs-only;releases nothing.

.changeset/lint-searchable-fields-type-validation.md

@@ -0,0 +1,31 @@
+---
+"@objectstack/lint": minor
+---
+
+feat(lint): 视图 `searchableFields` 按运行时同一套判定做构建期校验 —— 一个 lookup 笔误不再等到 400 才暴露 (#4830)
+
+视图(list view)的 `searchableFields` 会被客户端逐字回显为 `$searchFields` 覆盖参数,而
+REST 入口闸(#4254)会用 `resolveSearchFieldResolution`(`@objectstack/spec/data`)判定
+该对象的可搜索集合 —— 声明一个 lookup 等「不可搜索」字段,运行时会把**整条查询** 400
+(`INVALID_FIELD`),列表工具栏搜索对全体角色彻底不可用。此前 `compile`/`validate` 只查
+字段**存在性**,这类笔误全绿放行,只能靠人肉点搜索框发现。
+
+新增规则 `searchable-field-unsearchable`(error 级,新导出常量同名):对每个视图级
+narrowing(对象内建 `listViews`、`defineView` 的 `list`/`listViews`、react 页面的
+`<ListView searchableFields>`)按**运行时同一个函数**(`resolveSearchFieldResolution`,
+非复制的类型清单,杜绝再度漂移)判定 declared = enforced:
+
+- 对象未声明 `searchableFields`(auto 源):视图里出现 lookup/json/hidden/审计列等
+  auto-default 拒绝的字段 → 构建期 error,信息含类型与 400 后果,lookup 给出「镜像到本
+  对象 text/formula 字段」的处方;
+- 对象已声明(declared 源):视图条目超出对象声明集合 → 构建期 error(视图只能收窄、
+  不能放宽,ADR-0061);
+- 对象自身的 `searchableFields`(canonical)维持**只查存在性**:运行时 declared 分支按
+  存在过滤、不按类型过滤,声明即被引擎执行,构建期拒绝会误伤运行时接受的元数据
+  (ADR-0072 D1);
+- 注册表注入的系统列在 narrowing 中跳过判定(其运行时元数据对 linter 不可见,宁可漏报
+  不可误报)。
+
+内部核心 `checkSearchableFieldList` / `indexObjectSearchTargets`(模块级导出,未入包
+barrel)签名有变:索引值从 `Set<string> | null` 变为 `ObjectSearchTarget | null`,并新增
+可选 `role: 'canonical' | 'narrowing'`(默认 `'narrowing'`)参数。

.changeset/objectui-pin-changeset-from-declarations.md

@@ -0,0 +1,25 @@
+---
+---
+
+Tooling-only (#4731): the `@objectstack/console` changeset that `scripts/bump-objectui.sh`
+writes on an objectui pin bump is now derived from what objectui **declared** — the
+`.changeset/*.md` files added over the pinned range — instead of guessed from
+conventional-commit types on the subject line. Releases nothing; no package changes.
+
+The guess had three measured failure modes on one real range (`7d9734d5e321..785b8a5d432c`,
+53 non-merge commits): `grep -iE '^- (feat|fix)'` dropped **all 13** releasing commits that
+were not `feat`/`fix` — every breaking `refactor(...)!` among them, including
+`refactor(layout)!: delete PageNodeRenderer` and the burn-ledger batches (objectui#3220 /
+objectui#3224) — while pulling in **5** commits that release nothing at all (two of them
+`fix(ci)`); `head -40` truncated the list in silence at 34/40 used; and the bump level came
+from `grep -ciE '^feat'`, so a range of nothing but breaking refactors stamped `patch`.
+
+`scripts/objectui-changeset-digest.mjs` now answers the question the script actually needs
+answered — *does this commit ship in the frontend release?* — from objectui's own
+declaration: a `.changeset/*.md` with package names releases, an empty frontmatter block is
+changesets' own "release-nothing", and the declared `major`/`minor`/`patch` **is** the bump
+(no `^feat` inference left anywhere). Nothing is capped by default; a cap that does fire
+names the real remainder, the release-nothing changesets and changeset-less commits are
+counted in the body rather than dropped in silence, and an unwalkable range (shallow clone,
+initial pin) emits a list explicitly labelled degraded. Guarded by
+`pnpm check:objectui-changeset` (`--self-test`, wired into `Lint & Type Check`).