Merge remote-tracking branch 'origin/main' into claude/platform-migration-gating-764pf2

Author: claude

.changeset/adr-0106-metadata-fls-masking.md

@@ -0,0 +1,5 @@
+---
+---
+
+ADR-0106 (Proposed): metadata-plane FLS — per-caller masking of object
+schemas (#3661 step ③). Docs-only; releases nothing.

.changeset/analytics-effective-granularity.md

@@ -0,0 +1,36 @@
+---
+"@objectstack/service-analytics": patch
+---
+
+fix(analytics): apply the EFFECTIVE date granularity to bucket labels and drill ranges (#3588 follow-up)
+
+`selection.dateGranularity` (shipped in #3652) reached the `GROUP BY` but not the
+post-processing: the bucket-label formatter and the drill-range inverter both
+kept reading the DATASET dimension's default. A query was grouped one way and
+described another. Found by driving a real dashboard query in a browser against
+a dataset whose dimension declares `dateGranularity: 'month'`:
+
+- selection `year` → the row came back labelled **`1970-01`** — a year bucket
+  re-formatted with the dataset's month granularity, its `"2026"` key re-read as
+  2026 *milliseconds* past the epoch;
+- selection `day` → day buckets were re-labelled as months, so ten distinct days
+  collapsed into two duplicated keys;
+- selection `quarter` / `year` / `day` / `week` → `drillRanges` came back empty,
+  silently removing drill-through from every bucketed chart.
+
+Granularity precedence now lives in one exported function,
+`resolveDimensionGranularity`, called from all three sites that must agree — the
+query's `GROUP BY`, the label formatter, and the range inverter. The drift was
+possible only because each site resolved it independently.
+
+Two consequences beyond the override case:
+
+- A dataset dimension that declares **no** granularity but is bucketed by the
+  widget now gets drill ranges too. Previously the range sidecar keyed off the
+  dataset's own `dateGranularity`, so this case — the one #3588 is actually
+  about — could never drill.
+- `formatDateBucket` no longer mistakes a bare year key for an epoch timestamp.
+  A year bucket's canonical key IS `"2026"`, which is the only bucket key that
+  collides with the pure-digit epoch heuristic (`"2026-Q2"`, `"2026-07"` and
+  `"2026-07-15"` all fail it). Being idempotent over already-formatted keys is
+  that function's stated contract; the year case just never held.

.changeset/analytics-execute-aggregate-execution-context.md

@@ -0,0 +1,47 @@
+---
+"@objectstack/spec": minor
+"@objectstack/service-analytics": minor
+"@objectstack/verify": minor
+---
+
+feat(analytics): the executeAggregate bridge carries ExecutionContext — ADR-0021 D-C second belt
+
+The analytics→engine bridge now forwards the request's `ExecutionContext` to
+`engine.aggregate`, so the engine's own middleware chain scopes analytics reads
+independently of the analytics layer's `getReadScope`.
+
+**Why.** `BaseEngineOptions.context` has always been `.optional()`, so nothing
+forced the bridge to pass it — and it did not. An authenticated aggregate
+reached the engine with no principal, plugin-security's principal-less fall-open
+skipped its RLS injection, and the only thing left scoping the query was the
+strategy remembering to call `getReadScope`. #3597 was a strategy that did not,
+and both belts were off at once.
+
+`getReadScope` stays: the two resolve scope through different paths (engine
+middleware vs `security.getReadFilter`), and a deployment without
+plugin-security has only the analytics layer. This is depth, not a replacement.
+
+- `StrategyContext` gains `context?: ExecutionContext`, bound per call by
+  `AnalyticsService` from `query()` / `generateSql()` / `queryDataset()`.
+- `StrategyContext.executeAggregate` and the `AnalyticsServicePlugin` /
+  `AnalyticsService` `executeAggregate` config options gain `context?:
+  ExecutionContext`. **Custom bridges should forward it** to their engine; the
+  built-in auto-bridge does. Purely additive — an existing bridge that ignores
+  it keeps working exactly as before.
+- `DimensionLabelDeps.fetchRecordLabels` and `resolveDimensionLabels` each gain
+  an optional trailing `context`, beside the `scope` / `resolveScope` that
+  #3639 added — the same two-belt split as the aggregate path.
+- `BootOptions.analytics` (`@objectstack/verify`) overrides the
+  AnalyticsServicePlugin instance, so a gate can boot with the analytics belt
+  off and assert the engine-side belt alone still scopes.
+
+**Also fixed on the same seam:**
+
+- `fetchRecordLabels` — the dimension display-label lookup — is row-granular
+  (one row per record, real display names). #3639 gave it the analytics-layer
+  belt (the referenced object's own read scope); it now also carries the
+  context, so the engine scopes the same read independently.
+- `ObjectQLStrategy.generateSql` emitted no `WHERE` at all, so the
+  `/analytics/sql` preview read as an unscoped table scan while the real
+  aggregate was scoped. It now renders the caller's filters and the read scope.
+  The preview never executed, so this was misleading output rather than a leak.

.changeset/auth-route-ledger.md

@@ -0,0 +1,44 @@
+---
+"@objectstack/plugin-auth": patch
+"@objectstack/client": patch
+---
+
+test(plugin-auth): enumerate better-auth's route table — the `/auth/**` wildcard becomes 55 exact rows (#3656)
+
+The widest hole the #3642 capstone measured. That guard reports how many SDK
+calls match only a `**` prefix family rather than a resolvable route, and the
+answer was 60 of ~196 — with 54 on `* /auth/**`, the largest and most
+security-relevant namespace in the client. `auth.me` builds
+`/api/v1/auth/get-session`; a prefix claim cannot tell you better-auth still
+calls it that, and better-auth is a third-party dependency on its own release
+cadence (this repo already chased its 1.7 column drift in #3624 / #3647).
+
+`plugin-auth` mounts it with a single catch-all, so there are no per-route
+registration calls to capture the way tranche 3 captured
+`registerStorageRoutes`. The seam is `auth.api`: every better-auth endpoint
+carries `.path` and `.options.method`, so a live instance is the route table.
+
+`auth-route-ledger.ts` reads it, in two halves checked differently on purpose:
+
+- **55 reviewed rows** — every route the SDK calls, each naming its client
+  method, checked strictly against the live table. This is the rename detector.
+- **129-path mounted-surface inventory** — checked for exact equality both
+  ways, so a version bump that adds publicly-mounted auth endpoints becomes a
+  reviewable CI diff. Machine-maintained rather than reviewed prose: demanding
+  a rationale for all 129 would make every better-auth upgrade a hundred-row
+  review and the ledger would rot into rubber-stamping.
+
+Enumeration is config-dependent, so the inventory is pinned at the
+configuration enabling every plugin the SDK targets — the maximal surface —
+with the participating `OS_*` env vars cleared so a developer's shell cannot
+produce a spurious diff. Mutation-checked: renaming a ledgered route fails the
+suite naming it.
+
+The capstone guard now includes this ledger in its union and prefers exact rows
+over wildcard families when matching — without that ordering fix every
+`/auth/*` URL would still have been absorbed by `* /auth/**` and the new ledger
+would have changed nothing. Wildcard-only matches fall **60 → 3**; the ratchet
+moves with them. What remains is `* /ai/**`, whose routes `service-ai` builds
+at plugin start.
+
+No runtime change: a ledger, a guard, and the header/audit-doc notes.

.changeset/ci-cache-tier1-optimizations.md

@@ -0,0 +1,4 @@
+---
+---
+
+CI-only: turbo cache for the Release job, console-dist cache keyed on the objectui pin, restore-only turbo caches on PRs (main seeds them), CodeQL off pull_request (main push + weekly schedule), spec coverage moved to a nightly workflow. Releases nothing.

.changeset/delegable-scope-read-surface.md

@@ -0,0 +1,37 @@
+---
+"@objectstack/spec": minor
+"@objectstack/plugin-security": minor
+"@objectstack/rest": minor
+"@objectstack/client": minor
+---
+
+feat(authz): expose the caller's delegable scope — the read half of the
+delegated-administration gate (ADR-0090 D12 / ADR-0105 D8)
+
+`adminScope` decided writes but could not be READ: `assignablePermissionSets`
+lived only inside `delegated-admin-gate.ts`, so a UI offering "place this
+person in a unit, with these positions" (the D8 scoped-invitation form) had no
+way to narrow its pickers. It would list the whole tree and let the user
+discover the boundary by being refused — which turns an authorization gate into
+a validator and makes the boundary invisible until it bites.
+
+`ISecurityService.describeDelegableScope(callerContext)` answers it, exposed as
+`GET /api/v1/security/my-delegable-scope` and `client.security.describeDelegableScope()`:
+
+- `placeableBusinessUnitIds` — union of the subtrees where the caller may place
+  people (scopes granting `manageAssignments`);
+- `assignablePositions` — positions whose every distributed permission set the
+  caller may hand out (containment check included);
+- `scopes` — the held `adminScope`s with subtrees resolved, for attribution;
+- `isTenantAdmin` — unconstrained, with everything enumerated so a consumer
+  renders ONE uniform picker instead of special-casing.
+
+Computed by the same helpers the write gate enforces with, so an option this
+reports is one `assert()` accepts — a test asserts that agreement directly. It
+NARROWS; the gate still decides.
+
+Strictly self-scoped: no target-user parameter, so it discloses nothing beyond
+the authority the caller already holds (unlike `explain`, which has one and
+gates it). Fail-closed — unresolvable scopes contribute nothing, a caller with
+no delegated authority gets empty lists, and a deployment without
+`@objectstack/plugin-security` gets 501.

.changeset/dogfood-gate-cancelled-not-failure.md

@@ -0,0 +1,4 @@
+---
+---
+
+CI-only: the Dogfood Regression Gate no longer reports a superseded (cancelled) run as a failure — `cancelled` joins the pass branch, backed by a fail-fast experiment showing a real shard failure always aggregates as `failure`. Releases nothing.

.changeset/i18n-bundle-drift-sweep.md

@@ -0,0 +1,30 @@
+---
+"@objectstack/platform-objects": patch
+---
+
+fix(i18n): clear the accumulated drift in the generated translation bundles
+
+The committed bundles had fallen behind the spec on three independent axes.
+`os i18n extract` (merge mode — every existing translation is preserved)
+reconciles all of them:
+
+**Keys the spec no longer has**, still carrying translations in
+`*.metadata-forms.generated.ts`. All three were removed deliberately and are
+now *rejected* by the schema, so their entries were dead weight:
+
+- `capabilities.trash` / `capabilities.mru` — `enable.trash`/`enable.mru`
+  retired in the 16.x line (#2377), with tombstone guidance in
+  `UNKNOWN_KEY_GUIDANCE`.
+- agent `visibility` — removed 2026-07 (#1901).
+
+**Keys the spec gained** but the bundles never learned: the
+`summaryOperations.*` sub-fields (`object` / `function` / `field` /
+`relationshipField` / `filter`), and `sys_invitation.business_unit_id` /
+`positions` from the ADR-0105 D8 placement work.
+
+**Objects stuck on empty strings.** `sys_migration`'s labels and help text were
+committed as `""` in the ja-JP and es-ES bundles, which renders as *blank* in
+those locales rather than falling back to anything readable. They now carry the
+schema text like every other untranslated key.
+
+No API or schema change — this only affects what the UI displays.

.changeset/i18n-extract-check-flag.md

@@ -0,0 +1,26 @@
+---
+"@objectstack/cli": minor
+---
+
+feat(cli): `os i18n extract --check` — fail instead of writing when translation bundles have drifted
+
+Generated translation bundles had no freshness gate, so they rotted silently
+until someone happened to re-run the extractor by hand. #3670 found three
+distinct drifts sitting in the committed bundles at once: translations left
+behind for schema keys that had been REMOVED, keys the schema had GAINED with
+no entry at all, and an object whose labels were committed as empty strings
+(which renders blank rather than falling back to anything readable).
+
+`--check` writes nothing and exits non-zero when a fresh extract differs from
+what is committed in `--out`, listing each stale or missing file and printing
+the exact regenerate command. It runs the identical render path as a real
+extract — both branches iterate the same rendered set — so the check can never
+disagree with what writing would produce.
+
+It runs in **merge mode** like any other extract, so it never asks anyone to
+re-translate: an up-to-date bundle re-extracts byte-identically. Requires
+`--out`, since there is nothing to compare against without it.
+
+In this repo it is wired up as `pnpm check:i18n` and gated in CI, but the flag
+is on the CLI, so any consumer shipping generated bundles can gate them the
+same way.

.changeset/naming-drift-recheck.md

@@ -0,0 +1,11 @@
+---
+"@objectstack/cli": patch
+---
+
+fix(doctor): point the retired `reference_filters` hint at `lookupFilters` (#1878 §3 recheck)
+
+`os doctor`'s snake→camel rule table advised "Use `referenceFilters`
+(camelCase)" — a key REMOVED from `FieldSchema` in #2377/ADR-0049, which the
+non-strict schema silently strips. The live successor is `lookupFilters` (read
+by the objectui lookup picker). The rule now matches both spellings and names
+the right key.