Merge remote-tracking branch 'origin/main' into claude/issue-16320-retire-cron-typed-positions

Author: claude

.changeset/client-adopts-rotated-session-token.md

@@ -0,0 +1,27 @@
+---
+"@objectstack/client": minor
+---
+
+feat(client): a bearer-mode `ObjectStackClient` keeps the session the server rotates it onto (#16534)
+
+Three better-auth routes ROTATE the caller's session on success — they mint a new session, install it in `Set-Cookie` (and, through `bearer()`, in the `set-auth-token` response header), and DELETE the row the caller was presenting:
+
+| route | where the new credential is |
+| --- | --- |
+| `auth.twoFactor.verifyTotp()` on the enrolment lane | body — `token`, and it is the LIVE one (plugin-auth's `two-factor-rotated-token-echo` repairs the vendor's stale echo) |
+| `auth.changePassword({ revokeOtherSessions: true })` | body — `token` |
+| `auth.twoFactor.disable()` | **response header only** — the body is `{ status: true }` |
+
+A browser is carried across all three by its own cookie. A bearer client — this SDK's own mode — kept presenting the DELETED session's token, so its very next call answered `401 UNAUTHORIZED`. Measured against a real `AuthManager` (better-auth 1.7.2) over a real driver, driven through the real `ObjectStackClient`, `login → enable → verifyTotp → disable → deleteUser` could not run to the end without the caller re-seating `client.token` by hand between the steps.
+
+The three methods now adopt the rotated credential themselves, the way `login()` already adopts the token it is handed. The `token` members stay on the wire and stay declared, so a caller that keeps its own credential store is unaffected; what changes is that it no longer has to.
+
+**No public surface moves.** No new export, no new option or flag, no new key on any declared request or response type — the SDK stores a token the server already sends and this package already declares. Graded `minor` rather than `patch` because the published runtime behaviour of three methods moves for existing callers.
+
+## What does NOT change, deliberately
+
+The adoption is on those three routes only, never in the shared `fetch` wrapper. `set-auth-token` rides **every** response that stages a session cookie — `POST /update-user` stages one to carry the updated user without rotating anything — and it carries the SIGNED `<token>.<sig>` spelling while every JSON `token` echo carries the UNSIGNED one. A wrapper-level read would therefore rewrite the stored credential into a different spelling of the SAME session on ordinary traffic. `auth.me()`, `auth.sessions.list()`, `auth.updateUser()` and `auth.twoFactor.verifyBackupCode()` (which does not rotate — the vendor echoes the session it resolved at entry) all leave the stored credential byte-identical, and that is pinned.
+
+A cookie-only deployment sends no `set-auth-token`; there is then nothing to adopt and `twoFactor.disable()` leaves the stored credential exactly as it was. `changePassword` without `revokeOtherSessions` answers `token: null` and likewise stores nothing.
+
+The three TSDoc warnings that told bearer callers "this SDK does not store it" are updated in the same change.

.changeset/config-refusal-throws-so-json-faces-emit.md

@@ -0,0 +1,48 @@
+---
+"@objectstack/cli": patch
+---
+
+fix(cli): `resolveConfigPath` throws its two refusals so the ten `--json` faces emit their envelopes, and `os verify` gains the catch-all it never had (#15547)
+
+Every `--json` face in this CLI declares that it answers an error path with a
+payload. `resolveConfigPath()` was the one path that bypassed that declaration:
+it wrote its refusal and then called `process.exit(1)` **directly**, so nothing
+was thrown and the catch-all each command already carries — all of which sit
+downstream of a throw — never ran. Ten published faces answered a missing config
+file with an empty stdout.
+
+Measured before this change on the published entry `packages/cli/bin/run.js`,
+`NO_COLOR=1`, streams captured separately, exit read before any pipe — ten faces
+(`build` · `compile` · `diff` · `i18n check` · `i18n extract` · `info` · `lint` ·
+`migrate meta` · `validate` · `verify`) across both branches of the helper, 19
+runs: **exit 1, stdout 0 bytes, stderr 296 B (explicit path) / 123 B
+(auto-detect)** — and `JSON.parse` on that stdout throws in all 19. After: the
+same 19 runs answer **exit 1 with a parseable document on stdout**, stderr
+unchanged byte for byte.
+
+The refusals now throw `ConfigRefusalError`. That is not a new contract — it is
+this path being pulled back onto the one its callers had already published, so
+it adds **zero** accept-set members and **zero** error codes.
+
+Three properties hold it in place:
+
+- **No face becomes a crash dump.** `os verify` had no `try` at all — measured,
+  a throw through it produced an oclif error line and no payload where every
+  sibling emitted an envelope — so it gains the catch-all its nine siblings
+  already had, in this same change rather than after it.
+- **The text face does not narrow.** The refusal and both hint lines are still
+  written by the helper, to stderr, byte-identical: all 19 non-`--json` runs
+  compare equal before and after on stdout, on stderr and on exit status. The
+  catch-alls skip re-rendering the sentence a second time on stdout.
+- **No error code is minted.** The thrown error carries neither `code` nor
+  `httpStatus`, so `errorCodeFields()` contributes nothing and each face emits
+  its own bare `{ error }`. Whether that shape is right is **#15549**'s open
+  question, and this change deliberately does not answer it.
+
+The `--json` stdout-purity instrument is widened with the fix rather than after
+it: the pre-boot family's discovery moves into a shared module, the pin that
+drives it now demands a document (empty stdout no longer passes) and compares
+the text face's stderr as a whole string, and `json-stdout-purity.e2e.test.ts`
+— whose own discovery is `bootSchemaStack`-based and cannot see a command that
+fails above the kernel — reconciles against that population so neither half can
+be lost silently.

.changeset/dataset-select-dimension-option-i18n.md

@@ -0,0 +1,36 @@
+---
+"@objectstack/service-analytics": minor
+---
+
+**The published `DimensionLabelDeps` type (re-exported from this package's `index.ts`) gains
+one new optional key, `translateSelectOptions`** — the surface the level is graded against,
+per the same "a new key on a published exported type is the mechanical floor for clause ②"
+rule #16778 shipped under. Backward compatible (optional, additive, no removed/renamed key,
+no wire-shape change), so `minor` rather than `major`.
+
+A dataset's `select`-field dimension now renders its option label in the request's locale on
+a dataset-backed chart, matching what `GET /meta/object/:name` (and hence the console's list
+grid) already renders for the identical field.
+
+`dimension-labels.ts` resolved a select dimension's category label straight out of field
+metadata's authored `options[].label` — always the author's own-language text, since
+`SelectOptionSchema.label` is a plain string, never an inline locale map. The dotted
+cross-object arm (`field: 'contract.direction'`) was unaffected: a relationship-path field
+name never matches a key in the BASE object's own field map, so `resolveDimensionLabels`
+skips it via `if (!meta) continue` before either branch runs — this fix changes nothing on
+that path, and a regression test now pins that it is never even consulted.
+
+`DimensionLabelDeps` gains one new optional capability, `translateSelectOptions`, which the
+plugin bridge (`plugin.ts`) implements by calling `translateObject` (`@objectstack/spec/system`)
+— the SAME translator the object-metadata REST endpoint already uses — against the
+deployment's i18n bundle, when an `i18n` service is registered. No new export, no new spec
+key, no wire-shape change: `AnalyticsResult` carries the same `rows`/`fields` shape as before,
+and a kernel with no i18n service configured (or nothing for the requested locale) falls back
+to exactly today's authored-label text.
+
+A future widening of `LOOKUP_TYPES` (#16390) does **not** automatically inherit this: lookup /
+master_detail labels resolve through the separate `fetchRecordLabels` capability (a related
+RECORD's display name, not a field's authored `options[]`), which this change does not touch.
+It does lower the cost of adding translated lookup-record labels later, though — the i18n
+service bridge (`plugin.ts`'s `i18nService()` / `buildTranslationBundle()`) is now already
+wired into this package and is a `ctx.getService('i18n')` away from reuse.

.changeset/lookup-reference-target-gate.md

@@ -0,0 +1,25 @@
+---
+'@objectstack/lint': minor
+'@objectstack/cli': patch
+---
+
+`object-reference-unknown` now judges a field's `reference` — the target of `Field.lookup()` / `Field.masterDetail()` / `Field.user()` — with the same four-rung ladder it applies to every other object-name site, and `os build`'s per-package run resolves those names across the artifact's `packages[]`
+
+`FieldSchema.reference` is `z.string()`: the schema holds it present and non-empty on `lookup` / `master_detail`, and nothing anywhere asked whether the name resolved. So `os validate`, `os lint` and `os build` all exited 0 — no diagnostic of any severity — on `Field.lookup('zzz_object_that_does_not_exist')` (measured on 17.3.0), and the miss surfaced only at runtime: the record picker asking the REST layer for an object that is not registered (404 `OBJECT_NOT_FOUND`), `$expand` failing on the field, the form rendering a control that can never resolve a value.
+
+The site joins `validateObjectReferences` and rides its existing ladder, so the three commands judge it identically:
+
+1. resolves in the stack's own objects, or in the objects an entry of this artifact's `packages[]` provides → ok;
+2. resolves in `PLATFORM_PROVIDED_OBJECT_NAMES` (`sys_user`, the target `Field.user()` writes) → ok;
+3. unresolved and not platform-prefixed → **`error`** — `os validate` / `os build` / `os lint` exit 1;
+4. unresolved, platform-prefixed, registered by nothing (`sys_approval_process`) → the existing `object-reference-unregistered-platform` advisory.
+
+Judged: `lookup`, `master_detail`, `user`. Not judged, on purpose: `tree` (the object schema already refuses any target but the own name), a `reference` on a non-relationship type (inert), and `objectExtensions[].fields` (an extension targets an object another package owns, routinely one this artifact does not carry).
+
+## Migration
+
+**A build that used to pass can now fail.** Rung 3 is a new `error`-level refusal on a published accept set. Point the field at one of the stack's own objects, at an object another package of the same artifact ships, or at a platform object by its full name (`sys_user`, not `user`); the finding names the objects that resolve and suggests the nearest one.
+
+**A reference into a sibling package of the same release artifact resolves — it needs no annotation.** ADR-0130 makes the release artifact the co-ownership boundary, so `os build`'s per-package leg now hands each package's stack the artifact's `packages[]` as resolution context (`compile.ts`). A module's `crm_order.account` → its App package's `crm_account` is an ordinary rung-1 resolution on all three commands. This changes what a rule can resolve, never what it judges: the collections judged per package are still that package's own, and a name no entry of `packages[]` provides still errors on the per-package run exactly as it does on the union one.
+
+**A reference into another RELEASE ARTIFACT still has no rung** — an app naming an object a separate product ships (HotCLM's `clm_contract.crm_contract` → HotCRM). It is unresolved and unprefixed, so rung 3 refuses it. The declared escape for that case resolves against declared manifest dependencies and is its own change; ⛔ it is deliberately not an authored per-field marker, which would be a one-line switch that silences the gate.

.changeset/platform-admin-existing-holder-scan.md

@@ -0,0 +1,17 @@
+---
+"@objectstack/plugin-security": minor
+---
+
+The first-boot `already_have_admin` short-circuit now FINDS an existing platform admin instead of sampling for one, so a tenant's organization-admin count can no longer decide whether a second unscoped `admin_full_access` grant is minted.
+
+Before this change the holders read was `sys_user_permission_set` with **no `orderBy` and a cap of 50**, and the predicate that actually decides — `!organization_id` — was applied **client-side to whatever 50 rows the driver returned first**. `admin_full_access` is not only the platform-admin set: every *organization-scoped* grant of it writes a row carrying the same `permission_set_id`, so this population grows with the number of **org** admins, not platform admins. A tenant with fifty-odd of them filled the window with rows that all fail the filter, the short-circuit did not fire, a **second** unscoped grant was minted, and `claimSeedOwnership` re-owned the seeded business records to the newly promoted user — silently, because the boot logs a successful promotion exactly as on a genuinely fresh install. Measured on the real better-sqlite3 driver: with 60 organization-scoped grants plus one unscoped human grant, the unordered 50-row window contained 50 organization-scoped rows and not the one that decides.
+
+That is the guarantee #14348 case D pins — 「Moving an already-granted platform admin is reserved to the maintainer.」 — failing open by row count.
+
+- **The read asks the driver the narrow question first.** `{ permission_set_id, organization_id: null }`, ordered and bounded. Because it is narrowed server-side, no number of organization-scoped grants can crowd the answer out of a window.
+- **A second, ordered and bounded leg still applies the exact predicate.** It runs only when the narrow leg found nobody. This is deliberate rather than redundant: `organization_id: ''` is storable and reads back as `''` on both SQL families, which `!organization_id` counts as **unscoped** and `where: { organization_id: null }` does **not** return — so replacing the client-side predicate with the narrowed read alone would have made this guard fire *less* often and mint the very grant this fixes. Both legs are strictly additive to what the old read could see, so the guard can only fire more often than before, never less.
+- **The bound is never silent.** The scan pages 200 rows at a time up to a 5000-row ceiling, and reaching that ceiling without finding an unscoped human holder now WARNS — naming the ceiling, the number of rows examined, and the consequence (promoting from here would mint a second unscoped grant and re-own the seeded records).
+- **The answer says how many rows it examined.** `bootstrapPlatformAdmin`'s returned report gains an optional `adminGrantRowsExamined`, counted by row identity across both legs, on every return the guard reaches. A guard that had seen the whole population and one that had seen a truncated slice of it previously returned byte-identical payloads.
+- **The ordering is stated to the driver, and it is measured, not assumed.** `tryFind` answers `[]` when a query is refused, and on this guard `[]` reads as "no platform admin exists yet" — which promotes. An order this object could not serve would therefore be a silent relaxation, so `id` ascending was measured honoured through ObjectQL on both SQL driver families against the real declarations.
+
+Unchanged: an unscoped grant held by the seed identity `usr_system` still never counts, so a database where it was wrongly promoted stays self-healing on restart; the walled postures still mint no grant row and still point a legacy unscoped holder at the config path; and a genuinely fresh install still promotes exactly as before.

.changeset/plugin-security-read-fault-vs-empty.md

@@ -0,0 +1,13 @@
+---
+'@objectstack/plugin-security': patch
+---
+
+Tell a read that DID NOT ANSWER apart from a read that answered NOTHING at two boot-reconciler seams, so a transient storage fault can no longer withdraw a standing org-admin grant or report an unreadable catalog as an already-canonical one (#15840).
+
+`reconcileOrgAdminGrant`'s `sys_member` read swallowed a fault into `[]`, and `[]` is what that function reads as "this user is not an admin of this organization" — the input to a DELETE. One transient read fault therefore revoked a sitting admin's standing grant, and the store kept it withdrawn after the fault cleared; only a `debug` line separated that run from a healthy one. That read now reports at `error` and returns `{ action: 'skipped', reason: 'membership_unreadable' }`, performing no write at all for the pair: nothing is granted, so nothing widens, and nothing standing is destroyed. The next `sys_member` write and the `kernel:ready` backfill ask again.
+
+`normalizeManagedByVocab` swallowed a catalog read fault into `[]` too, so an unreadable catalog and an already-canonical one were byte-identical on both channels — the same `{ positions: 0, permissionSets: 0 }` and zero log lines at any level — while the row that needed healing stayed legacy. A read that does not answer now reports at `error` and refuses the pass instead of attesting counts it could not read. The refusal aborts at the first un-answered read, so it is one line per refused boot rather than the four the report-and-continue shape measured. Its only production consumer already declared the handling: the `kernel:ready` bootstrap catches it, reports it at `warn` as non-fatal, and boot proceeds.
+
+⭐ Per-site, not a sweep. A genuine EMPTY read keeps today's behaviour EXACTLY at both seams — a demotion with no membership row still revokes, a membership still grants, an already-canonical catalog still answers `{ positions: 0, permissionSets: 0 }` in silence. `claim-seed-ownership.ts` is untouched: its fault already propagates to a per-predicate handler that reports at `warn` and names the consequence, which is the right disposition already. The plugin's other reads keep their existing best-effort contract, where an unanswered read costs a grant that is not created rather than one that is destroyed.
+
+No exported symbol, published payload key or spec path changes: `action: 'skipped'` is already in the returned union, `reason` is already free text, and the two logger option types gain an optional `error` method a caller may omit. Healthy-path behaviour is byte-identical; only the fault path moves.

.changeset/preview-count-over-field-non-null.md

@@ -0,0 +1,34 @@
+---
+'@objectstack/service-analytics': patch
+---
+
+Draft-preview analytics: `count` over a declared field counts its non-null values, matching every live face
+
+A dataset measure `{ aggregate: 'count', field: 'payer' }` compiles to the cube
+metric `{ type: 'count', sql: 'payer' }`, and the draft-preview evaluator carried
+that field in and never read it — it answered the ROW count, nulls included,
+while every SQL face lowers the same measure to `COUNT("payer")`, defined over
+non-null values. A drafted chart therefore showed a different number than the
+published one, silently, and the number it showed was the one `count(*)` gives:
+the author's choice to count a specific column had no effect on the preview path.
+
+Measured on one dataset, one row set, two `AnalyticsService` instances differing
+only in `draftRowsResolver` (the live half being `NativeSQLStrategy`'s generated
+SQL on a real SQLite): rows `{meals, 'bob'}` and `{meals, null}` answered
+`payer_count` 1 live and 2 on preview. Both now answer 1.
+
+Unchanged, and pinned by the same differential: `count` with no field and `count`
+with `field: '*'` still answer the row count (the compiler writes
+`sql: m.field ?? '*'`, so the star is the "no field declared" spelling), and
+`count_distinct` still answers a cardinality. A group in which no row carries a
+value counts `0`, never null — `emptyGroupValueFor` rules counting nothing the
+identity `0`.
+
+The live path is unchanged.
+
+Bumped `patch` rather than `minor`: the package's published surface is
+byte-unchanged — `src/index.ts` is not in this diff, `aggregate()` is
+module-private and `evaluateAnalyticsQueryOverRows` is not on the barrel — and
+the only user-visible effect is a drafted chart's number moving to the number
+the published chart already showed, which is a correction toward the live
+standard rather than the backwards-compatible feature addition `minor` denotes.