merge main into #4001 remeasure (pick up #4856 60s timeout)

Author: claude

.changeset/analytics-compare-measure-filters.md

@@ -0,0 +1,56 @@
+---
+"@objectstack/service-analytics": patch
+---
+
+fix(service-analytics): `compareTo` applies measure-scoped filters, so `<measure>__compare` is the same measure as the column beside it (#4820)
+
+A dataset measure declared with its own `filter` is scoped by running a
+supplementary grouped sub-query — `combineFilters(baseFilter, measureFilters[m])`
+— and merging it back by dimension key. The `compareTo` pass did not: it issued
+**one** shifted query over every base measure with only the base filter as its
+`where`, and never consulted `compiled.measureFilters` at all.
+
+For a dataset like
+
+```ts
+measures: [
+  { name: 'revenue',   aggregate: 'sum',   field: 'amount' },
+  { name: 'won_count', aggregate: 'count', filter: { stage: 'closed_won' } },
+]
+```
+
+the current-period column was scoped and the comparison column was not — two
+different measures rendered side by side under one label:
+
+| # | measures | where | |
+|:---|:---|:---|:---|
+| 1 | `revenue` | — | current |
+| 2 | `won_count` | `{"stage":"closed_won"}` | current |
+| 3 | `revenue`, `won_count` | **absent** | shifted |
+
+`won_count__compare` was therefore a count of **every** opportunity in the
+previous window, inflated by exactly the rows the measure exists to exclude.
+The error runs one way: the comparison period always looks better, so a "won
+deals vs. last month" tile reads as a collapse when nothing went wrong. Only
+filter-scoped measures were affected — the unfiltered ones next to them compared
+correctly, which is what made it survive.
+
+The comparison window now runs the **same pass** as the current period —
+unfiltered measures in one shifted query plus one shifted sub-query per
+filter-scoped measure, merged by dimension key — through a single shared
+implementation, so the two paths cannot re-diverge at the next change. The
+dataset filter, the presentation's `runtimeFilter` and the measure's own filter
+compose identically in both windows; the only difference between them is the
+shifted `dateRange`.
+
+Numbers reported by existing dashboards change where a filtered measure was
+compared: with 3 won deals this month against 1 won of 5 opportunities last
+month, `won_count__compare` was `5` and is now `1`.
+
+Cost: one extra query per filter-scoped measure when `compareTo` is set.
+Selections whose measures carry no filter are untouched and still compare in a
+single shifted query.
+
+The empty-group fill (#4708) covers the new seam: a group the measure's filter
+empties in the *previous* window now reports `0` for a `count`/`sum` compare
+column rather than blanking it, exactly as it already did for the current period.

.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/auth-otp-cooldown-retention-follows-config.md

@@ -0,0 +1,38 @@
+---
+"@objectstack/plugin-auth": patch
+---
+
+fix(plugin-auth): OTP 冷却按声明值真正生效 —— 发送历史的保留时长不再被硬编码的 1 小时截断 (#4808)
+
+`OtpSendGuard` 有**两个**维度:每号码「距上次发送至少 N 秒」的冷却(`cooldownSeconds`),
+和每号码「滚动一小时内至多 M 条」的上限(`maxPerHour`)。它们需要**不同**的时间窗,而此前
+两者共用了同一个硬编码的一小时:发送历史按 1 小时剪枝、也按 1 小时写 TTL。
+
+于是把 `phoneOtp.cooldownSeconds` 配成**大于 3600** 时:配置被接受,没有校验错误,没有 warn,
+但冷却所依据的那条历史记录在 1 小时处就被丢掉了 —— 声明「两次发送间隔 2 小时」,实际最多
+只有 1 小时,**反滥用强度是声明值的一半,而且没有任何信号**(ADR-0049 声明 ≠ 强制)。
+计价单位仍然是真金白银的短信。这与 #4790 是同一个 guard 上的**不同**缺陷,且改动前后行为
+一致 —— 不是 #4806 引入的。
+
+**修法(issue 的方向 1):保留时长跟随配置。** 历史保留 `max(1 小时, cooldownSeconds)`,
+即「两个维度里还用得着它的那个更长的窗」;TTL 同步跟随,记录因此活得比它所度量的冷却更久。
+每小时上限仍在**它自己的滚动一小时**内计数,所以超长冷却不会反过来把 `maxPerHour` 收得比
+声明的更严。
+
+**上限是拒绝,不是又一次截断。** `cooldownSeconds` 超过 `MAX_COOLDOWN_SECONDS`(86400,
+即 24 小时)会在**启动时**抛错(`AuthPlugin.init()` 构造 `AuthManager` 处),错误信息给出
+值、上限和改法。把截断点挪到更高的数字只是把同一个缺陷往外推一个量级;设上限的理由是:
+一条号码的历史会在共享缓存里驻留整个冷却期,而超过一天的封锁已经不是发送节流而是账号锁定
+(另一套机制、另一套管控)。这条边界同时把「`cooldownSeconds` 误填成毫秒」这类笔误变成
+一次响亮的拒绝(5 分钟以上的意图都会被挡下)。校验放在**配置处**而不是首次发送处:guard
+是惰性构造的,只在那里校验的话,一个配置错误会表现为 `/phone-number/send-otp` 的 500。
+
+**默认配置行为完全未变**,并有测试锁定:未配置 `phoneOtp` 时仍是 60 秒冷却 + 每小时 5 条,
+历史保留与 TTL 仍是 3600 秒。
+
+对使用者的影响:
+
+- `phoneOtp.cooldownSeconds` 现在在 1 小时以上也真正生效(上限 24 小时);
+- 超过 24 小时、负数或非有限值的配置**开始被拒绝**——这些值此前从未按声明工作过(要么被
+  静默截断到 1 小时,要么被静默钳成 0 即关闭冷却),因此不存在依赖其旧行为的部署;
+- 新增导出:常量 `MAX_COOLDOWN_SECONDS` 与校验函数 `assertOtpCooldownSeconds()`。

.changeset/batch-row-error-codes-registered.md

@@ -0,0 +1,26 @@
+---
+"@objectstack/spec": minor
+---
+
+feat(spec): register `ROLLED_BACK` / `NOT_ATTEMPTED` batch-row error codes; record the batch-row shape migration (#4793)
+
+Support for the `@objectstack/metadata-protocol` v17 batch-row migration
+(#4793 — see its major changeset for the wire change itself):
+
+- `ERROR_CODE_LEDGER` registers two codes under `@objectstack/metadata-protocol`:
+  `ROLLED_BACK` (atomic data-batch row was written, then undone by the batch
+  rollback) and `NOT_ATTEMPTED` (row never ran — an earlier row's failure
+  aborted the batch). They are the structured, `ApiError.code`-level form of
+  the message-string prefixes #4620 introduced; `ApiErrorSchema.code` now
+  accepts them and clients branch on the code instead of regexing messages.
+- The ADR-0087 migration registry gains the protocol-17 semantic entry
+  `batch-row-result-schema-shape` (a RESPONSE surface — nothing stored to
+  rewrite, so it is a documented TODO for readers of the legacy `row.error` /
+  `row.record` keys), and `docs/protocol-upgrade-guide.md` is regenerated
+  with it.
+- `BatchOptionsSchema.atomic` / `BatchOperationResultSchema.errors` describe
+  strings now document the code-based rollback marking (reference docs
+  regenerated).
+
+No schema *shape* changes: `BatchOperationResultSchema` already declared
+`errors` / `data` / `index` — the runtime caught up to it.

.changeset/batch-row-result-schema-shape.md

@@ -0,0 +1,48 @@
+---
+"@objectstack/metadata-protocol": major
+---
+
+fix(metadata-protocol)!: batch per-row results now deliver the declared `BatchOperationResultSchema` shape (#4793)
+
+**Breaking wire change** on the per-row `results` entries of the three
+bulk-write endpoints — `POST /data/:object/batch`, `/updateMany`,
+`/deleteMany`. The rows had drifted from the schema that declares them:
+`BatchOperationResultSchema`, the client SDK's exported `BatchOperationResult`
+type and the reference docs all said `errors: ApiError[]` / `data` / `index`,
+while the wire carried `error: string` / `record` and never sent `index`. A
+TypeScript consumer written against the published type compiled, validated,
+and read `undefined` at runtime. The wire now delivers exactly what is
+declared (a conformance pin parses every emitted row against the schema, so
+the two cannot silently fork again).
+
+**FROM → TO, per row:**
+
+| Before (legacy wire) | After (declared schema) | Your fix |
+| --- | --- | --- |
+| `row.error` (string) | `row.errors` (`ApiError[]`) | read `row.errors?.[0]?.message`; branch on `row.errors?.[0]?.code` |
+| `row.record` | `row.data` | rename the read |
+| — (never sent) | `row.index` (number) | new — the row's position in the request array; use it to correlate failure rows that carry no `id` |
+| `row.droppedFields` | `row.droppedFields` | unchanged |
+
+**Rollback marking is structured now.** The `ROLLED_BACK:` /
+`NOT_ATTEMPTED:` message-string prefixes that #4620 introduced (see the
+`many-data-atomic-real-or-refused` changeset — its description of those
+markers is superseded by this entry) are promoted to first-class
+`ApiError.code` values, registered in the spec's ERROR_CODE_LEDGER:
+
+- `errors[0].code === 'ROLLED_BACK'` — the row was written, then undone by the
+  atomic batch rollback; `message` carries the causal row's index and error.
+- `errors[0].code === 'NOT_ATTEMPTED'` — the row never ran; an earlier row's
+  failure aborted the batch.
+- the causal row keeps its own error code (e.g. `RECORD_NOT_FOUND`,
+  `VALIDATION_FAILED`; an unclassified engine throw maps to `INTERNAL_ERROR`,
+  with `httpStatus` mirrored when the error carried one).
+
+Branch on the code — do **not** regex message prefixes; the prefixes are gone.
+
+**Who is affected:** only readers of the *legacy* keys — which were never in
+the schema or the SDK types, so they were reachable only via `as any` or bare
+JS. Code written against `BatchOperationResult` (the published contract) needed
+this change to start working and needs no migration. There is no
+dual-emission or compatibility fallback: this is a hard cut inside the v17
+major window, and the old keys simply no longer exist on the wire.

.changeset/book-job-translation-app-authorwarn-keys-retired.md

@@ -39,8 +39,14 @@ Run `os migrate meta --from 16` to rewrite existing sources automatically.
   migration table steered retired `errors:` authors straight into it. **That
   guidance entry is rewritten here**: retiring one dead key by pointing at
   another is the defect, not the fix.
-- **`app.homePageId`** — *its own hedge*. "If not set, usually defaults to the
-  first navigation item" described the only behaviour there was.
+- **`app.homePageId`** — *a second source for one fact*. Not unread: objectui's
+  console consumed it in `resolveLandingRoute()` and it was the only thing
+  deciding where an app opened. (This entry first shipped saying otherwise;
+  corrected in #4709, which upheld the removal.) What condemns the key is its
+  shape — an ID cross-reference into `navigation` with no referential integrity,
+  falling back to the first item *silently* when the id dangled. If "land
+  somewhere other than first" is ever wanted again it belongs on the navigation
+  item itself, not on a pointer that can miss.
 - **`app.areas[].order`** — *the sibling that works*. Nav-item `order` really is
   sorted; area-level order never was, and both renderers iterate the array as
   authored.

.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/ci-merge-queue-throughput.md

@@ -0,0 +1,4 @@
+---
+---
+
+CI-only (#4859): Test Core / Dogfood 各 2→3 分片 + merge-queue 失败自动分诊评论 workflow。仅 `.github/workflows/**`，不发布任何包。