Merge origin/main into claude/issue-4986-unique-scope-vocab

Resolves the scripts/adr-anchors.json conflict by keeping all five
ADR-0120 anchor entries (spec/lint side + driver side from #5212), and
clears the os-regen deferred merge of packages/spec/api-surface.json via
spec build + gen:api-surface (isOrganizationUnique retained).

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

Author: claude

.changeset/audit-skip-sys-job-queue.md

@@ -0,0 +1,32 @@
+---
+"@objectstack/plugin-audit": patch
+---
+
+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`).

.changeset/audit-skip-sys-upload-session.md

@@ -0,0 +1,35 @@
+---
+"@objectstack/plugin-audit": patch
+---
+
+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.

.changeset/auth-membership-policy-setting.md

@@ -0,0 +1,49 @@
+---
+"@objectstack/plugin-auth": minor
+"@objectstack/service-settings": minor
+---
+
+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`.

.changeset/chart-drilldown-declared.md

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

.changeset/cluster-peer-write-invalidates-caches.md

@@ -0,0 +1,39 @@
+---
+"@objectstack/metadata": patch
+---
+
+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`)仍然先于失效判断,本节点自己的广播不会让自己白白重建缓存。

.changeset/database-loader-read-outage-is-not-a-miss.md

@@ -0,0 +1,39 @@
+---
+"@objectstack/metadata": patch
+---
+
+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`,
+所以存储故障现在会从它们抛出,而不再静默答「不存在」/「空清单」。这正是本次修复要的
+姿态 —— 可用性故障不是一次「没有」。