Merge remote-tracking branch 'origin/main' into claude/issue-20378-diff-draft-versions

Claude-Session: https://claude.ai/code/session_local_1d2a197c-c20e-4e90-9be8-413d4d432289
Co-authored-by: Claude <noreply@anthropic.com>

Author: hotlong

.changeset/20320-dispatcher-meta-read-parity.md

@@ -0,0 +1,54 @@
+---
+'@objectstack/rest': minor
+'@objectstack/runtime': patch
+---
+
+fix(rest, runtime): the runtime dispatcher's `/meta` reads answer what `RestServer`'s answer — one list chain, one `public`-audience predicate, and the `?state=draft` read (#20320)
+
+Clause-②: yes (widening) — `@objectstack/rest`'s root entry gains five value exports (`createMetaListAnswer`, `translateMetaList`, `metaRequestLocale`, `isPublicAudienceRead`, `STORED_VERSION_DOOR_POLICY`) and six type exports (`MetaListAnswer`, `MetaListAnswerSources`, `MetaListRequest`, `MetaListTranslationSources`, `MetaPublicReadRoute`, `MetaRequestHttp`), so its published surface grows; nothing it exported before is removed, renamed or narrowed. `@objectstack/runtime` publishes no new surface and stays a `patch`.
+
+A host that mounts only the `${prefix}/*` catch-all (`createHonoApp`, and any
+adapter written on the public `HttpDispatcher` API) serves `/meta` through the
+runtime dispatcher. Its reads now give the same answers as `RestServer`'s
+`GET /meta/:type` and `GET /meta/:type/:name`. Until now a dispatcher-only host
+answered:
+
+- **`GET /meta/app?id=crm`** — every app the caller may see, not `[crm]`. An
+  `?id=` that matches nothing listed every app instead of an empty list.
+- **`GET /meta/view?object=lead`** — every view, not the lead views sorted for
+  the switcher.
+- **`GET /meta/docs`** (the plural spelling) — every doc WITH its body. The
+  content slim compared the raw segment, so it ran only for `/meta/doc`.
+- **any doc list** — each doc with its `translations` map and in no locale.
+  `RestServer` collapses each doc to the request's locale.
+- **every translatable list** (`app`, `view`, `object`, `page`, `dashboard`,
+  `action`, `dataset`) — untranslated labels, whatever `Accept-Language` or
+  `?locale=` asked for, and no `Vary: Accept-Language` header.
+- **`GET /meta/api`** — every stored `api` declaration, including ones the
+  endpoint matcher does not serve (their routes answer 404).
+- **an anonymous `GET` of a `public` book or doc** (list or item) —
+  `401 UNAUTHENTICATED`. `RestServer` serves it (ADR-0046 §6.7).
+- **`GET /meta/:type/:name?state=draft` from a caller who may read drafts** —
+  the ACTIVE item. It should be the pending draft, whole for a caller who may
+  save the app and pruned per caller for everyone else, or `404 NO_DRAFT` when
+  nothing is pending. A caller who may not read drafts is still answered the
+  plain read, byte for byte.
+
+**What changed.** The list route's whole post-read chain moved out of
+`RestServer` into `createMetaListAnswer` in `@objectstack/rest`, unchanged. That
+chain is the `api` served-set face, the per-caller list gate, `?id=`,
+`?object=`, the doc locale collapse and content slim, the transport's own
+object mask, and the translation. Every exit of the dispatcher's list branch
+now hands its answer to that same function. The anonymous gates on both
+transports ask one exported predicate, `isPublicAudienceRead`. It admits only
+`GET` reads of book and doc, so every other type keeps the anonymous deny, and
+the §6.7 audience gate still refuses `org` and `{ permissionSet }` audiences.
+The dispatcher's `?state=draft` read runs the exported
+`STORED_VERSION_DOOR_POLICY`, the constant `RestServer`'s draft branch runs.
+
+`RestServer`'s own answers are unchanged: the move is a refactor on that side,
+and every existing REST test passes unedited.
+
+New exports from `@objectstack/rest`: `createMetaListAnswer`,
+`translateMetaList`, `metaRequestLocale`, `isPublicAudienceRead`,
+`STORED_VERSION_DOOR_POLICY` and their types. Nothing is removed or renamed.

.changeset/20381-adhoc-cube-request-scope.md

@@ -7,5 +7,5 @@
 Clause-②: no
 
 - **What changes**: both ad-hoc doors — `query()` (`POST /api/v1/analytics/query`) and `generateSql()` (`POST /api/v1/analytics/sql`) — resolved the query's cube and recorded what `ensureCube` minted straight into the shared registry, ahead of the admission check. A request refused `PERMISSION_DENIED` still left the cube it inferred for the refused object in the registry, and a suffix measure a caller named on a registered cube (`<field>_sum`, `<field>_count_distinct`, …) was appended to that cube for every later reader, whether the request was refused or admitted. Both doors now run in the same request-local scope `queryDataset` runs in: what `ensureCube` mints stays with the call, and the admission, read scope and strategy all read it from there.
-- **What does not change**: every request is served as before, with the same admission, read scope, refusals, codes and statuses, and a caller-named suffix measure is still served to the caller who named it. An ADMITTED ad-hoc query over an object with no configured cube still registers the cube it inferred, as before — now only after the admission has admitted the request, and never over a cube registered under the same name in the meantime. Configured cubes and datasets registered at construction (`AnalyticsServiceConfig.cubes` / `datasets`) are untouched.
-- **What `getMeta()` lists, the one observable difference**: `getMeta()` and `GET /api/v1/analytics/meta` no longer list a cube inferred for a refused request, and no longer list a suffix measure some caller named on a registered cube — a registered cube is listed as it was registered. A cube inferred for an admitted request is still listed.
+- **What does not change**: every request is served as before, with the same admission, read scope, refusals, codes and statuses, and a caller-named suffix measure is still served to the caller who named it. A cube inferred for an ADMITTED ad-hoc query is no longer registered either; the separate #20381 entry that retires inferred-cube registration describes that change. Configured cubes and datasets registered at construction (`AnalyticsServiceConfig.cubes` / `datasets`) are untouched.
+- **What `getMeta()` lists, the one observable difference**: `getMeta()` and `GET /api/v1/analytics/meta` no longer list a cube inferred for a refused request, and no longer list a suffix measure some caller named on a registered cube — a registered cube is listed as it was registered.

.changeset/20381-retire-inferred-cube-source.md

@@ -0,0 +1,11 @@
+---
+"@objectstack/service-analytics": patch
+---
+
+A cube `AnalyticsService` infers for an ad-hoc `query()` or `generateSql()` request is no longer registered in the service-wide cube registry, even when the request is admitted, so `getMeta()` and `GET /api/v1/analytics/meta` list configured cubes only (#20381).
+
+Clause-②: no
+
+- **What changes**: an ad-hoc request naming an object that no cube is configured over (`POST /api/v1/analytics/query`, `POST /api/v1/analytics/sql`) is still served from a minimal cube inferred from that request's own members. That cube now lives only in the request that inferred it, like a suffix measure a caller appends to a configured cube. Before, an admitted request left it in the shared registry, so `getMeta()` listed it to every caller, including callers who may not read the object, together with the member names the first caller used. Its contents depended on who had queried what since boot, and it was lost on restart.
+- **What does not change**: every request is served as before, with the same answer, admission, read scope, refusals, codes and statuses. A repeat request for the same object infers the cube again, through the same existence and source-field checks, and gets the same answer. Configured cubes (`AnalyticsServiceConfig.cubes`) and datasets registered through `registerDataset` (the constructor's `datasets`, or an embedder) are registered and listed as before, and they are now the registry's only writers.
+- **What to do**: nothing, unless something reads `getMeta()` / `GET /api/v1/analytics/meta` expecting to find a cube that only an ad-hoc query inferred. No consumer in this repository does. Author that cube explicitly (`defineCube`, or the analytics service's `cubes` config) so that it is listed, and listed the same way after a restart.

.changeset/20412-auth-settings-sibling-isolation.md

@@ -0,0 +1,35 @@
+---
+'@objectstack/plugin-auth': patch
+---
+
+**plugin-auth: a refused auth setting no longer drops the other settings saved with it**
+
+Clause-②: no
+
+The `auth` settings pass used to go to `AuthManager.applyConfigPatch()` as ONE patch. When the
+manager refused one key in it, the whole patch was dropped: password policy, MFA, rate limits,
+session lifetime and social providers from that pass were not applied. The settings console
+still showed every one of them as saved, and the only trace was a `warn`.
+
+Reachable examples:
+
+- posture `open` (declared in stack config, or opened earlier through the console) with
+  `auth.require_email_verification: false` stored through the console;
+- posture `email_domain` with `OS_AUTH_REQUIRE_EMAIL_VERIFICATION=false`;
+- the SCIM/admin coherence refusal on the `plugins` block, once `OS_SCIM_ENABLED` appears after
+  the manager was constructed with `plugins.admin: false`.
+
+Now the pass is applied in pieces, split where the manager can refuse. Each key that lands in
+the `emailAndPassword` or `plugins` block is applied on its own; every other key goes out in one
+application the manager does not validate. `mfa_required` stays one piece with the `twoFactor`
+plugin it turns on, so MFA is never enforced without its enrollment endpoints. The manager's
+verdict on each piece is the verdict; no validation moved into the plugin.
+
+A refusal is logged once, at `error`, naming the key:
+`[auth] auth settings REFUSED (auth.require_email_verification) — the standing runtime value
+keeps ruling …`, followed by the manager's own message, which carries the remedy. Every other
+setting in the pass still applies. A pass that fails as a whole, such as a settings namespace
+that cannot be read, is also logged at `error` (`[auth] auth settings NOT APPLIED — …`).
+
+The old `Auth: failed to apply auth settings:` warning is gone. A log alert that matched it
+should match `[auth] auth settings REFUSED` and `[auth] auth settings NOT APPLIED` instead.