Merge remote-tracking branch 'origin/main' into claude/issue-4001-ui-batch13

Author: claude

.changeset/cli-banner-tenancy-posture.md

@@ -0,0 +1,53 @@
+---
+"@objectstack/cli": patch
+---
+
+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`.

.changeset/dashboard-widget-responsive-removed.md

@@ -0,0 +1,73 @@
+---
+"@objectstack/spec": major
+---
+
+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.

.changeset/node-and-shutdown-timeout-guards-cleared.md

@@ -0,0 +1,30 @@
+---
+'@objectstack/service-automation': patch
+'@objectstack/core': patch
+---
+
+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`)一个都没动 —— 问题从来不在时长,而在没人回收。

.changeset/now-default-token-engine-resolved.md

@@ -0,0 +1,54 @@
+---
+"@objectstack/objectql": patch
+---
+
+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.

.changeset/org-axis-red-lines-read-spec-keys.md

@@ -0,0 +1,43 @@
+---
+"@objectstack/lint": minor
+---
+
+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.

.changeset/sharing-rule-unlowerable-condition-gate.md

@@ -0,0 +1,58 @@
+---
+"@objectstack/lint": minor
+---
+
+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.