merge: origin/main (#4995 responsive retirement) into #4956 widget drill

Conflict was `liveness/dashboard.json`'s `_note` only; both sides kept and
reconciled. #4876/#4995 recorded that `widgets[].responsive` deliberately
carries NO ledger row because one would be an ORPHAN — true only while
`widgets` was undrilled. The retiredKey tombstone keeps the key in the walked
shape, so with the drill landed the row is REQUIRED (omitting it reports
UNCLASSIFIED); it is present with the dead verdict the #3896 sweep never got to
record. check:liveness green on the merged tree is the arbiter.

os-regen four-step done: generated artifacts taken wholesale from origin/main,
rebuilt, check:generated clean on the merged source, and every #4995 sibling
entry asserted present (authorable-surface [RETIRED], spec-changes, upgrade
guide, conversions registry, tombstone, changeset).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ehu85kbvMcrNTUJjwxvLJ9

Author: claude

.changeset/adr-0105-d6-unit-and-subordinates.md

@@ -0,0 +1,34 @@
+---
+"@objectstack/lint": patch
+---
+
+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** —— 不产生新红。

.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/dogfood-typecheck-wired.md

@@ -0,0 +1,15 @@
+---
+---
+
+ci(dx): `packages/qa/dogfood` 的 strict tsconfig 现在真的被执行 —— 加上 `typecheck` script 并从 `scripts/check-type-check-coverage.mjs` 的 DEBT 账本毕业(#4855)。Dev scripts / CI only;releases nothing。
+
+dogfood 有一份认真的 tsconfig(`strict`、`NodeNext`、`include: ["src/**/*", "test/**/*"]`),但 package.json 的 scripts 里只有 `test`。根 `pnpm typecheck` 是 `turbo run typecheck`,只跑声明了该 script 的包 —— 三个 qa 包里,这是唯一没声明的一个,所以这份配置**从未被执行过**。#4311 的覆盖率闸门确实看见了这个洞,但把它记成 DEBT(`errors: 12`)冻结了下来,而 DEBT 是「暂缓」不是「豁免」:门后的错误只会继续涨。在最新 main 上实测是 **14** 条,比账本冻结时多了 2 条 —— 正是这种漂移说明冻结不能长期替代执行。
+
+14 条全部修掉,分四类:
+
+- **NodeNext 缺扩展名(2 条,TS2307)** —— `field-zoo-roundtrip.dogfood.test.ts` 与 `field-zoo-value-shape.test.ts` 写 `from './field-zoo.matrix'`。包内另外 33 处相对 import 全都带 `.js`,这两处是仅有的例外。vitest 能解析,tsc 不能。附带消掉 1 条级联的 TS7006(未解析的 import 让符号退化成 `any`,回调参数随即报 implicit-any)。
+- **flow fixture 的 `type` 没有收窄(8 条,TS2322)** —— 四个 fixture 的 flow 是裸对象字面量,`type: 'autolaunched'` 推成 `string`,喂给 `defineStack` 时对不上字面量联合。修法不是 `as const`,而是按 `examples/app-todo/src/flows/task.flow.ts` 的既有写法标注 `: Flow`(`import type { Flow } from '@objectstack/spec/automation'`)—— 这样整份 fixture 都被 spec 的真实契约检查,而不只是让报错闭嘴。
+- **条件展开出的 headers(2 条,TS2322)** —— `attachments-permission-matrix.dogfood.test.ts` 的 `token ? { Authorization } : {}` 在匿名分支上推出 `Authorization?: undefined`,展开进 `headers` 后 `HeadersInit`(`Record< string, string >`)拒收。给该常量标注 `Record< string, string >`。
+- **连接器 handler 少传一个参数(1 条,TS2554)** —— `showcase-mcp-self-connection.dogfood.test.ts` 调 `handler!({})`,而 `McpConnectorBundle.handlers` 声明的是 `(input, ctx)`,引擎侧 `connector-nodes.ts` 也始终按两参数派发。这条一直「能跑」,只是因为 MCP 这个 handler 恰好忽略 `ctx` —— 契约上它是错的。改为按声明传两参数,与 connector-mcp 自己的测试一致;**没有放松任何契约**(把 `ctx` 改成可选才是错误方向)。
+
+修完接进执行:package.json 加 `"typecheck": "tsc --noEmit"`,并按闸门的 RECONCILED 不变式在同一个 PR 里删掉 DEBT 条目(graduated)。覆盖率从 60/77 走到 61/77,DEBT 从 17 个包降到 16 个。反向验证:在 fixture 里塞一个非法的 flow `type`,`turbo run typecheck` 判红并精确指出该行;移回后判绿(命中修复前那一次绿跑的同一个 turbo hash)。`pnpm --filter @objectstack/dogfood test` 481 passed / 3 skipped,行为未变。

.changeset/host-declared-package-resolution.md

@@ -0,0 +1,64 @@
+---
+"@objectstack/types": minor
+"@objectstack/cli": minor
+"@objectstack/verify": minor
+---
+
+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`。

.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.