Skip to content

chore: version packages#3387

Merged
os-zhuang merged 1 commit into
mainfrom
changeset-release/main
Jul 22, 2026
Merged

chore: version packages#3387
os-zhuang merged 1 commit into
mainfrom
changeset-release/main

Conversation

@github-actions

@github-actions github-actions Bot commented Jul 21, 2026

Copy link
Copy Markdown
Contributor

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

@objectstack/cli@16.1.0

Minor Changes

  • 9e45b63: feat(cli): preflight that every requires capability has an installable provider
    in the current edition (Preflight that required capabilities have an installable provider in the current edition #3366)

    A capability listed in requires: [...] was only checked at serve/start time,
    and a missing provider produced a generic "not installed — add it to your
    dependencies" error even when the provider has no installable version in the
    current edition
    . os validate (token-vocabulary only) and os build (never
    resolved providers) both passed, so a validate && build && test CI script never
    caught it — it surfaced only as an opaque boot crash. Seen upgrading an
    open-edition app from 14.7 to 16 after @objectstack/service-ai went
    cloud-only (ADR-0025).

    • @objectstack/spec/kernel now exports PLATFORM_CAPABILITY_PROVIDERS
      (token → provider package + edition) and a pure classifyRequiredCapability()
      one machine-readable source of truth for the provider/edition knowledge the
      serve resolver previously encoded informally.
    • os build and os validate gained a provider preflight. A requires entry
      whose provider has no installable version in the active edition (e.g. ai
      @objectstack/service-ai, cloud-only) now fails fast with an edition-aware
      message; an absent-but-installable provider is an advisory pnpm add hint, not
      a hard error; a satisfied requires list passes unchanged.
    • The os serve boot error now renders the same classification, so preflight and
      boot read identically.
  • db160dd: Flag dead action/route references in dashboard header & widget actions (ADR-0049 for references, Flag dead action/route references in dashboard header actions (ADR-0049 for references) #3367).

    os validate / os build now run a new validateDashboardActionRefs gate over every dashboard header.actions[] and widget actionUrl:

    • actionType: 'script' | 'modal'error unless actionUrl resolves to a defined action (stack.actions or an object's actions). modal also resolves via the runtime <verb>_<object> convention (create_/new_/add_/edit_/update_ + a real object) and bare object names. A dangling target ships a button that renders and silently does nothing on click — a false affordance, exactly the "declared ≠ enforced" gap ADR-0049 closes, applied to references.
    • actionType: 'url'warning when a relative in-app path names a objects/reports/dashboards/pages/views route whose target does not exist in the stack. External URLs, interpolated (${…}) targets, and opaque routes are skipped to keep false positives near zero.

Patch Changes

  • Updated dependencies [212b66a]
  • Updated dependencies [d10c4dc]
  • Updated dependencies [9e45b63]
  • Updated dependencies [7b07417]
  • Updated dependencies [fa006fb]
  • Updated dependencies [db160dd]
  • Updated dependencies [b20201f]
  • Updated dependencies [818e6a3]
    • @objectstack/platform-objects@16.1.0
    • @objectstack/spec@16.1.0
    • @objectstack/console@16.1.0
    • @objectstack/lint@16.1.0
    • @objectstack/core@16.1.0
    • @objectstack/service-automation@16.1.0
    • @objectstack/trigger-record-change@16.1.0
    • @objectstack/observability@16.1.0
    • @objectstack/rest@16.1.0
    • @objectstack/plugin-hono-server@16.1.0
    • @objectstack/runtime@16.1.0
    • @objectstack/account@16.1.0
    • @objectstack/setup@16.1.0
    • @objectstack/metadata@16.1.0
    • @objectstack/plugin-approvals@16.1.0
    • @objectstack/plugin-audit@16.1.0
    • @objectstack/plugin-auth@16.1.0
    • @objectstack/plugin-email@16.1.0
    • @objectstack/plugin-reports@16.1.0
    • @objectstack/plugin-security@16.1.0
    • @objectstack/plugin-sharing@16.1.0
    • @objectstack/service-job@16.1.0
    • @objectstack/service-queue@16.1.0
    • @objectstack/service-realtime@16.1.0
    • @objectstack/service-settings@16.1.0
    • @objectstack/service-storage@16.1.0
    • @objectstack/client@16.1.0
    • @objectstack/cloud-connection@16.1.0
    • @objectstack/formula@16.1.0
    • @objectstack/mcp@16.1.0
    • @objectstack/objectql@16.1.0
    • @objectstack/driver-memory@16.1.0
    • @objectstack/driver-mongodb@16.1.0
    • @objectstack/driver-sql@16.1.0
    • @objectstack/driver-sqlite-wasm@16.1.0
    • @objectstack/plugin-webhooks@16.1.0
    • @objectstack/service-analytics@16.1.0
    • @objectstack/service-cache@16.1.0
    • @objectstack/service-datasource@16.1.0
    • @objectstack/service-messaging@16.1.0
    • @objectstack/service-package@16.1.0
    • @objectstack/service-sms@16.1.0
    • @objectstack/trigger-api@16.1.0
    • @objectstack/trigger-schedule@16.1.0
    • @objectstack/types@16.1.0
    • @objectstack/verify@16.1.0
    • @objectstack/plugin-pinyin-search@16.1.0

@objectstack/console@16.1.0

Minor Changes

@objectstack/core@16.1.0

Minor Changes

  • b20201f: fix(service-automation): runAs:'user' runs data ops with the triggering user's
    real permission sets + positions, not a bare member fallback (service-automation: runAs:'user' runs data ops with a credential-less user — trigger context never carries the actor's permission sets/positions (follow-up to #1888) #3356, follow-up to
    [P0][security] Flow runAs never switches execution identity #1888)

    Since [P0][security] Flow runAs never switches execution identity #1888 the automation engine honours flow.runAs (system elevates), but
    the runAs:'user' credential propagation was hollow. A record-change-triggered
    runAs:'user' flow ran its data nodes (update_record, …) with a zero-grant
    principal — only the member/everyone baseline — even when the triggering user
    was fully authorized. Two faces by object config: a private object 403'd the
    in-flow write (not permitted for positions [org_member, everyone] — the user's
    permission sets were invisible); a public_read_write object let the write
    through but silently stripped readonly/FLS-gated fields. The root cause: the
    ObjectQL record-change hook session carries only a userId — never the writer's
    positions/permission sets — and nothing in between resolved them, so the comment
    promising "enforces RLS exactly as the user who made the change" never held.

    The fix resolves the triggering user's actual authorization at run setup, from
    the same tables a direct REST request resolves through:

    • @objectstack/core factors the userId-driven core of resolveAuthzContext
      into a new exported resolveUserAuthzGrants(ql, userId, opts) — the single place
      that reads sys_member / sys_user_position / sys_*_permission_set and
      derives positions, permission-set names, platform_admin, and posture. The
      HTTP resolver now delegates to it (behaviour byte-identical; the full contract
      suite still passes), so a non-HTTP surface that already knows the user id builds
      the SAME envelope instead of re-implementing the reads.
    • @objectstack/service-automation gains AutomationEngine.setUserGrantsResolver,
      wired by the plugin to resolveUserAuthzGrants over the objectql/data engine.
      For a runAs:'user' run whose trigger left the authz envelope unresolved (no
      permissions), the engine now resolves the user's positions + permission sets
      once at run setup and threads them into every data node's ObjectQL context —
      so the run enforces RLS/FLS exactly as that user. Contexts that already carry
      permissions are left untouched (a REST trigger, and notably an ADR-0090 agent
      ceiling acting on-behalf-of a user — always non-empty — so a deliberately
      narrowed identity is never re-broadened). runAs:'system' is unchanged, and a
      resolver error fails safe (warns, keeps the bare user — never elevates).
    • @objectstack/trigger-record-change stops forwarding the misleading
      half-populated positions (empty in practice, and never permissions) from the
      hook session; it forwards userId + tenant only and lets the engine resolve the
      full grants authoritatively.

    When no ObjectQL engine is present (bare engine / tests) the resolver is unwired
    and run identity is unchanged from before.

Patch Changes

  • Updated dependencies [9e45b63]
    • @objectstack/spec@16.1.0

@objectstack/lint@16.1.0

Minor Changes

  • fa006fb: Validate dashboard filter field-existence at build time (extend ADR-0021, Validate dashboard filter field-existence at build time (extend ADR-0021) #3365).

    validateWidgetBindings now checks that every dashboard-level filter (dateRange

    • each globalFilters[]) resolves to a real field on each bound widget's dataset
      object. Since Dashboard-level filters (date / region) driving multiple charts #2501 wired these filters into every widget's analytics query, a
      filter field absent on a widget's object — e.g. a dateRange bound to
      close_date inherited by an account/contact widget over a different object —
      emitted invalid SQL (no such column: close_date) and crashed the widget at
      render time. That build-decidable invariant previously escaped os validate /
      os build and failed only when a user opened the dashboard.

    It now fails the build (new rule dashboard-filter-field-unknown) with a message
    naming the dashboard, widget, filter, field, and object, unless the widget opts
    out via filterBindings: { <name>: false } or re-targets to an existing field —
    mirroring the field-existence invariant ADR-0032 enforces for CEL references.
    Effective-field resolution matches the runtime (filterBindings re-target /
    opt-out, legacy targetWidgets allow-list, filter default). Registry-injected
    system fields (e.g. created_at, the dateRange default) and objects outside
    the validated stack never false-positive.

  • db160dd: Flag dead action/route references in dashboard header & widget actions (ADR-0049 for references, Flag dead action/route references in dashboard header actions (ADR-0049 for references) #3367).

    os validate / os build now run a new validateDashboardActionRefs gate over every dashboard header.actions[] and widget actionUrl:

    • actionType: 'script' | 'modal'error unless actionUrl resolves to a defined action (stack.actions or an object's actions). modal also resolves via the runtime <verb>_<object> convention (create_/new_/add_/edit_/update_ + a real object) and bare object names. A dangling target ships a button that renders and silently does nothing on click — a false affordance, exactly the "declared ≠ enforced" gap ADR-0049 closes, applied to references.
    • actionType: 'url'warning when a relative in-app path names a objects/reports/dashboards/pages/views route whose target does not exist in the stack. External URLs, interpolated (${…}) targets, and opaque routes are skipped to keep false positives near zero.

Patch Changes

  • Updated dependencies [9e45b63]
    • @objectstack/spec@16.1.0
    • @objectstack/formula@16.1.0
    • @objectstack/sdui-parser@16.1.0

@objectstack/service-automation@16.1.0

Minor Changes

  • b20201f: fix(service-automation): runAs:'user' runs data ops with the triggering user's
    real permission sets + positions, not a bare member fallback (service-automation: runAs:'user' runs data ops with a credential-less user — trigger context never carries the actor's permission sets/positions (follow-up to #1888) #3356, follow-up to
    [P0][security] Flow runAs never switches execution identity #1888)

    Since [P0][security] Flow runAs never switches execution identity #1888 the automation engine honours flow.runAs (system elevates), but
    the runAs:'user' credential propagation was hollow. A record-change-triggered
    runAs:'user' flow ran its data nodes (update_record, …) with a zero-grant
    principal — only the member/everyone baseline — even when the triggering user
    was fully authorized. Two faces by object config: a private object 403'd the
    in-flow write (not permitted for positions [org_member, everyone] — the user's
    permission sets were invisible); a public_read_write object let the write
    through but silently stripped readonly/FLS-gated fields. The root cause: the
    ObjectQL record-change hook session carries only a userId — never the writer's
    positions/permission sets — and nothing in between resolved them, so the comment
    promising "enforces RLS exactly as the user who made the change" never held.

    The fix resolves the triggering user's actual authorization at run setup, from
    the same tables a direct REST request resolves through:

    • @objectstack/core factors the userId-driven core of resolveAuthzContext
      into a new exported resolveUserAuthzGrants(ql, userId, opts) — the single place
      that reads sys_member / sys_user_position / sys_*_permission_set and
      derives positions, permission-set names, platform_admin, and posture. The
      HTTP resolver now delegates to it (behaviour byte-identical; the full contract
      suite still passes), so a non-HTTP surface that already knows the user id builds
      the SAME envelope instead of re-implementing the reads.
    • @objectstack/service-automation gains AutomationEngine.setUserGrantsResolver,
      wired by the plugin to resolveUserAuthzGrants over the objectql/data engine.
      For a runAs:'user' run whose trigger left the authz envelope unresolved (no
      permissions), the engine now resolves the user's positions + permission sets
      once at run setup and threads them into every data node's ObjectQL context —
      so the run enforces RLS/FLS exactly as that user. Contexts that already carry
      permissions are left untouched (a REST trigger, and notably an ADR-0090 agent
      ceiling acting on-behalf-of a user — always non-empty — so a deliberately
      narrowed identity is never re-broadened). runAs:'system' is unchanged, and a
      resolver error fails safe (warns, keeps the bare user — never elevates).
    • @objectstack/trigger-record-change stops forwarding the misleading
      half-populated positions (empty in practice, and never permissions) from the
      hook session; it forwards userId + tenant only and lets the engine resolve the
      full grants authoritatively.

    When no ObjectQL engine is present (bare engine / tests) the resolver is unwired
    and run identity is unchanged from before.

Patch Changes

  • Updated dependencies [9e45b63]
  • Updated dependencies [b20201f]
    • @objectstack/spec@16.1.0
    • @objectstack/core@16.1.0
    • @objectstack/formula@16.1.0

@objectstack/spec@16.1.0

Minor Changes

  • 9e45b63: feat(cli): preflight that every requires capability has an installable provider
    in the current edition (Preflight that required capabilities have an installable provider in the current edition #3366)

    A capability listed in requires: [...] was only checked at serve/start time,
    and a missing provider produced a generic "not installed — add it to your
    dependencies" error even when the provider has no installable version in the
    current edition
    . os validate (token-vocabulary only) and os build (never
    resolved providers) both passed, so a validate && build && test CI script never
    caught it — it surfaced only as an opaque boot crash. Seen upgrading an
    open-edition app from 14.7 to 16 after @objectstack/service-ai went
    cloud-only (ADR-0025).

    • @objectstack/spec/kernel now exports PLATFORM_CAPABILITY_PROVIDERS
      (token → provider package + edition) and a pure classifyRequiredCapability()
      one machine-readable source of truth for the provider/edition knowledge the
      serve resolver previously encoded informally.
    • os build and os validate gained a provider preflight. A requires entry
      whose provider has no installable version in the active edition (e.g. ai
      @objectstack/service-ai, cloud-only) now fails fast with an edition-aware
      message; an absent-but-installable provider is an advisory pnpm add hint, not
      a hard error; a satisfied requires list passes unchanged.
    • The os serve boot error now renders the same classification, so preflight and
      boot read identically.

@objectstack/hono@16.1.0

Patch Changes

  • Updated dependencies [818e6a3]
    • @objectstack/plugin-hono-server@16.1.0
    • @objectstack/runtime@16.1.0
    • @objectstack/types@16.1.0

@objectstack/account@16.1.0

Patch Changes

  • Updated dependencies [212b66a]
  • Updated dependencies [d10c4dc]
  • Updated dependencies [9e45b63]
    • @objectstack/platform-objects@16.1.0
    • @objectstack/spec@16.1.0

@objectstack/setup@16.1.0

Patch Changes

  • Updated dependencies [212b66a]
  • Updated dependencies [d10c4dc]
  • Updated dependencies [9e45b63]
    • @objectstack/platform-objects@16.1.0
    • @objectstack/spec@16.1.0

@objectstack/studio@16.1.0

Patch Changes

  • Updated dependencies [212b66a]
  • Updated dependencies [d10c4dc]
  • Updated dependencies [9e45b63]
    • @objectstack/platform-objects@16.1.0
    • @objectstack/spec@16.1.0

@objectstack/client@16.1.0

Patch Changes

  • Updated dependencies [9e45b63]
  • Updated dependencies [b20201f]
    • @objectstack/spec@16.1.0
    • @objectstack/core@16.1.0

@objectstack/client-react@16.1.0

Patch Changes

  • Updated dependencies [9e45b63]
  • Updated dependencies [b20201f]
    • @objectstack/spec@16.1.0
    • @objectstack/core@16.1.0
    • @objectstack/client@16.1.0

@objectstack/cloud-connection@16.1.0

Patch Changes

  • Updated dependencies [9e45b63]
  • Updated dependencies [b20201f]
  • Updated dependencies [818e6a3]
    • @objectstack/spec@16.1.0
    • @objectstack/core@16.1.0
    • @objectstack/runtime@16.1.0
    • @objectstack/types@16.1.0

@objectstack/connector-mcp@16.1.0

Patch Changes

  • Updated dependencies [9e45b63]
  • Updated dependencies [b20201f]
    • @objectstack/spec@16.1.0
    • @objectstack/core@16.1.0

@objectstack/connector-openapi@16.1.0

Patch Changes

  • Updated dependencies [9e45b63]
  • Updated dependencies [b20201f]
    • @objectstack/spec@16.1.0
    • @objectstack/core@16.1.0

@objectstack/connector-rest@16.1.0

Patch Changes

  • Updated dependencies [9e45b63]
  • Updated dependencies [b20201f]
    • @objectstack/spec@16.1.0
    • @objectstack/core@16.1.0

@objectstack/connector-slack@16.1.0

Patch Changes

  • Updated dependencies [9e45b63]
  • Updated dependencies [b20201f]
    • @objectstack/spec@16.1.0
    • @objectstack/core@16.1.0

@objectstack/formula@16.1.0

Patch Changes

  • Updated dependencies [9e45b63]
    • @objectstack/spec@16.1.0

@objectstack/mcp@16.1.0

Patch Changes

  • Updated dependencies [9e45b63]
  • Updated dependencies [b20201f]
    • @objectstack/spec@16.1.0
    • @objectstack/core@16.1.0
    • @objectstack/formula@16.1.0
    • @objectstack/types@16.1.0

@objectstack/metadata@16.1.0

Patch Changes

  • Updated dependencies [212b66a]
  • Updated dependencies [d10c4dc]
  • Updated dependencies [9e45b63]
  • Updated dependencies [b20201f]
    • @objectstack/platform-objects@16.1.0
    • @objectstack/spec@16.1.0
    • @objectstack/core@16.1.0
    • @objectstack/metadata-core@16.1.0
    • @objectstack/types@16.1.0
    • @objectstack/metadata-fs@16.1.0

@objectstack/metadata-core@16.1.0

Patch Changes

  • Updated dependencies [9e45b63]
    • @objectstack/spec@16.1.0

@objectstack/metadata-fs@16.1.0

Patch Changes

  • @objectstack/metadata-core@16.1.0

@objectstack/metadata-protocol@16.1.0

Patch Changes

  • Updated dependencies [9e45b63]
  • Updated dependencies [b20201f]
    • @objectstack/spec@16.1.0
    • @objectstack/core@16.1.0
    • @objectstack/formula@16.1.0
    • @objectstack/metadata-core@16.1.0
    • @objectstack/types@16.1.0

@objectstack/objectql@16.1.0

Patch Changes

  • Updated dependencies [9e45b63]
  • Updated dependencies [b20201f]
    • @objectstack/spec@16.1.0
    • @objectstack/core@16.1.0
    • @objectstack/formula@16.1.0
    • @objectstack/metadata-core@16.1.0
    • @objectstack/metadata-protocol@16.1.0
    • @objectstack/types@16.1.0

@objectstack/observability@16.1.0

Patch Changes

  • 818e6a3: fix(server-timing): emit the per-request, admin-gated Server-Timing header on the standard server (os serve/dev) (v16.0: per-request admin-gated Server-Timing never emits on the hono server (os serve/dev) #3361)

    The per-request Server-Timing path (feat(observability): per-request performance timing → Server-Timing (perf-tuning mode) #2408) — where an admin sends
    X-OS-Debug-Timing: 1 (or json) and gets phase timings while an ordinary user
    gets nothing — never emitted on the shipped Hono server. The disclosure gate the
    Hono middleware opens is only ever flipped by the runtime dispatcher's
    timedResolveExecutionContext, but the data (/api/v1/data/*) and metadata
    (/api/v1/meta/*) routes on os serve/dev are served by @objectstack/rest's
    RestServer (which shadows the Hono plugin's own CRUD), and its identity
    resolver never opened the gate. Only global mode (OS_SERVER_TIMING=true) — which
    discloses to every caller, not just admins — worked.

    • observability: the disclosure predicate isPerfDisclosurePrincipal(ec) now
      lives here (the home of the gate), the single definition of "who may pull
      per-request timings" shared by every HTTP entry point. @objectstack/runtime
      re-exports it for back-compat.
    • rest: RestServer.resolveExecCtx opens the gate for an admin/service
      principal (via the carried posture rung), the REST-server analog of the
      dispatcher — this is the fix that makes os serve/dev emit.
    • plugin-hono-server: the standalone CRUD surface's self-contained
      resolveCtx opens the gate too (deriving the rung for the gate decision only,
      never writing it onto the enforcement context). Adds an e2e test that boots the
      Hono app and asserts an admin gets Server-Timing while a member/anon does not.
  • Updated dependencies [9e45b63]

    • @objectstack/spec@16.1.0

@objectstack/platform-objects@16.1.0

Patch Changes

@objectstack/driver-memory@16.1.0

Patch Changes

  • Updated dependencies [9e45b63]
  • Updated dependencies [b20201f]
    • @objectstack/spec@16.1.0
    • @objectstack/core@16.1.0

@objectstack/driver-mongodb@16.1.0

Patch Changes

  • Updated dependencies [9e45b63]
  • Updated dependencies [b20201f]
    • @objectstack/spec@16.1.0
    • @objectstack/core@16.1.0

@objectstack/driver-sql@16.1.0

Patch Changes

  • Updated dependencies [9e45b63]
  • Updated dependencies [b20201f]
  • Updated dependencies [818e6a3]
    • @objectstack/spec@16.1.0
    • @objectstack/core@16.1.0
    • @objectstack/observability@16.1.0
    • @objectstack/types@16.1.0

@objectstack/driver-sqlite-wasm@16.1.0

Patch Changes

  • Updated dependencies [9e45b63]
  • Updated dependencies [b20201f]
    • @objectstack/spec@16.1.0
    • @objectstack/core@16.1.0
    • @objectstack/driver-sql@16.1.0

@objectstack/embedder-openai@16.1.0

Patch Changes

  • Updated dependencies [9e45b63]
    • @objectstack/spec@16.1.0

@objectstack/knowledge-memory@16.1.0

Patch Changes

  • Updated dependencies [9e45b63]
  • Updated dependencies [b20201f]
    • @objectstack/spec@16.1.0
    • @objectstack/core@16.1.0
    • @objectstack/service-knowledge@16.1.0

@objectstack/knowledge-ragflow@16.1.0

Patch Changes

  • Updated dependencies [9e45b63]
  • Updated dependencies [b20201f]
    • @objectstack/spec@16.1.0
    • @objectstack/core@16.1.0
    • @objectstack/service-knowledge@16.1.0

@objectstack/plugin-approvals@16.1.0

Patch Changes

  • Updated dependencies [212b66a]
  • Updated dependencies [d10c4dc]
  • Updated dependencies [9e45b63]
  • Updated dependencies [b20201f]
    • @objectstack/platform-objects@16.1.0
    • @objectstack/spec@16.1.0
    • @objectstack/core@16.1.0
    • @objectstack/formula@16.1.0
    • @objectstack/metadata-core@16.1.0

@objectstack/plugin-audit@16.1.0

Patch Changes

  • Updated dependencies [212b66a]
  • Updated dependencies [d10c4dc]
  • Updated dependencies [9e45b63]
  • Updated dependencies [b20201f]
    • @objectstack/platform-objects@16.1.0
    • @objectstack/spec@16.1.0
    • @objectstack/core@16.1.0

@objectstack/plugin-auth@16.1.0

Patch Changes

  • Updated dependencies [212b66a]
  • Updated dependencies [d10c4dc]
  • Updated dependencies [9e45b63]
  • Updated dependencies [b20201f]
  • Updated dependencies [818e6a3]
    • @objectstack/platform-objects@16.1.0
    • @objectstack/spec@16.1.0
    • @objectstack/core@16.1.0
    • @objectstack/rest@16.1.0
    • @objectstack/types@16.1.0

@objectstack/plugin-dev@16.1.0

Patch Changes

  • Updated dependencies [9e45b63]
  • Updated dependencies [b20201f]
  • Updated dependencies [818e6a3]
    • @objectstack/spec@16.1.0
    • @objectstack/core@16.1.0
    • @objectstack/rest@16.1.0
    • @objectstack/plugin-hono-server@16.1.0
    • @objectstack/runtime@16.1.0
    • @objectstack/account@16.1.0
    • @objectstack/setup@16.1.0
    • @objectstack/plugin-auth@16.1.0
    • @objectstack/plugin-security@16.1.0
    • @objectstack/objectql@16.1.0
    • @objectstack/driver-memory@16.1.0
    • @objectstack/service-i18n@16.1.0
    • @objectstack/types@16.1.0

@objectstack/plugin-email@16.1.0

Patch Changes

  • Updated dependencies [212b66a]
  • Updated dependencies [d10c4dc]
  • Updated dependencies [9e45b63]
  • Updated dependencies [b20201f]
    • @objectstack/platform-objects@16.1.0
    • @objectstack/spec@16.1.0
    • @objectstack/core@16.1.0
    • @objectstack/formula@16.1.0

@objectstack/plugin-hono-server@16.1.0

Patch Changes

  • 818e6a3: fix(server-timing): emit the per-request, admin-gated Server-Timing header on the standard server (os serve/dev) (v16.0: per-request admin-gated Server-Timing never emits on the hono server (os serve/dev) #3361)

    The per-request Server-Timing path (feat(observability): per-request performance timing → Server-Timing (perf-tuning mode) #2408) — where an admin sends
    X-OS-Debug-Timing: 1 (or json) and gets phase timings while an ordinary user
    gets nothing — never emitted on the shipped Hono server. The disclosure gate the
    Hono middleware opens is only ever flipped by the runtime dispatcher's
    timedResolveExecutionContext, but the data (/api/v1/data/*) and metadata
    (/api/v1/meta/*) routes on os serve/dev are served by @objectstack/rest's
    RestServer (which shadows the Hono plugin's own CRUD), and its identity
    resolver never opened the gate. Only global mode (OS_SERVER_TIMING=true) — which
    discloses to every caller, not just admins — worked.

    • observability: the disclosure predicate isPerfDisclosurePrincipal(ec) now
      lives here (the home of the gate), the single definition of "who may pull
      per-request timings" shared by every HTTP entry point. @objectstack/runtime
      re-exports it for back-compat.
    • rest: RestServer.resolveExecCtx opens the gate for an admin/service
      principal (via the carried posture rung), the REST-server analog of the
      dispatcher — this is the fix that makes os serve/dev emit.
    • plugin-hono-server: the standalone CRUD surface's self-contained
      resolveCtx opens the gate too (deriving the rung for the gate decision only,
      never writing it onto the enforcement context). Adds an e2e test that boots the
      Hono app and asserts an admin gets Server-Timing while a member/anon does not.
  • Updated dependencies [9e45b63]

  • Updated dependencies [b20201f]

  • Updated dependencies [818e6a3]

    • @objectstack/spec@16.1.0
    • @objectstack/core@16.1.0
    • @objectstack/observability@16.1.0
    • @objectstack/types@16.1.0

@objectstack/plugin-pinyin-search@16.1.0

Patch Changes

  • Updated dependencies [b20201f]
    • @objectstack/core@16.1.0
    • @objectstack/objectql@16.1.0
    • @objectstack/types@16.1.0

@objectstack/plugin-reports@16.1.0

Patch Changes

  • Updated dependencies [212b66a]
  • Updated dependencies [d10c4dc]
  • Updated dependencies [9e45b63]
  • Updated dependencies [b20201f]
    • @objectstack/platform-objects@16.1.0
    • @objectstack/spec@16.1.0
    • @objectstack/core@16.1.0

@objectstack/plugin-security@16.1.0

Patch Changes

  • Updated dependencies [212b66a]
  • Updated dependencies [d10c4dc]
  • Updated dependencies [9e45b63]
  • Updated dependencies [b20201f]
    • @objectstack/platform-objects@16.1.0
    • @objectstack/spec@16.1.0
    • @objectstack/core@16.1.0
    • @objectstack/formula@16.1.0

@objectstack/plugin-sharing@16.1.0

Patch Changes

  • Updated dependencies [212b66a]
  • Updated dependencies [d10c4dc]
  • Updated dependencies [9e45b63]
  • Updated dependencies [b20201f]
    • @objectstack/platform-objects@16.1.0
    • @objectstack/spec@16.1.0
    • @objectstack/core@16.1.0
    • @objectstack/formula@16.1.0
    • @objectstack/objectql@16.1.0

@objectstack/plugin-webhooks@16.1.0

Patch Changes

  • Updated dependencies [9e45b63]
  • Updated dependencies [b20201f]
    • @objectstack/spec@16.1.0
    • @objectstack/core@16.1.0
    • @objectstack/service-messaging@16.1.0

@objectstack/rest@16.1.0

Patch Changes

  • 818e6a3: fix(server-timing): emit the per-request, admin-gated Server-Timing header on the standard server (os serve/dev) (v16.0: per-request admin-gated Server-Timing never emits on the hono server (os serve/dev) #3361)

    The per-request Server-Timing path (feat(observability): per-request performance timing → Server-Timing (perf-tuning mode) #2408) — where an admin sends
    X-OS-Debug-Timing: 1 (or json) and gets phase timings while an ordinary user
    gets nothing — never emitted on the shipped Hono server. The disclosure gate the
    Hono middleware opens is only ever flipped by the runtime dispatcher's
    timedResolveExecutionContext, but the data (/api/v1/data/*) and metadata
    (/api/v1/meta/*) routes on os serve/dev are served by @objectstack/rest's
    RestServer (which shadows the Hono plugin's own CRUD), and its identity
    resolver never opened the gate. Only global mode (OS_SERVER_TIMING=true) — which
    discloses to every caller, not just admins — worked.

    • observability: the disclosure predicate isPerfDisclosurePrincipal(ec) now
      lives here (the home of the gate), the single definition of "who may pull
      per-request timings" shared by every HTTP entry point. @objectstack/runtime
      re-exports it for back-compat.
    • rest: RestServer.resolveExecCtx opens the gate for an admin/service
      principal (via the carried posture rung), the REST-server analog of the
      dispatcher — this is the fix that makes os serve/dev emit.
    • plugin-hono-server: the standalone CRUD surface's self-contained
      resolveCtx opens the gate too (deriving the rung for the gate decision only,
      never writing it onto the enforcement context). Adds an e2e test that boots the
      Hono app and asserts an admin gets Server-Timing while a member/anon does not.
  • Updated dependencies [212b66a]

  • Updated dependencies [d10c4dc]

  • Updated dependencies [9e45b63]

  • Updated dependencies [b20201f]

  • Updated dependencies [818e6a3]

    • @objectstack/platform-objects@16.1.0
    • @objectstack/spec@16.1.0
    • @objectstack/core@16.1.0
    • @objectstack/observability@16.1.0
    • @objectstack/service-package@16.1.0
    • @objectstack/types@16.1.0

@objectstack/runtime@16.1.0

Patch Changes

  • 818e6a3: fix(server-timing): emit the per-request, admin-gated Server-Timing header on the standard server (os serve/dev) (v16.0: per-request admin-gated Server-Timing never emits on the hono server (os serve/dev) #3361)

    The per-request Server-Timing path (feat(observability): per-request performance timing → Server-Timing (perf-tuning mode) #2408) — where an admin sends
    X-OS-Debug-Timing: 1 (or json) and gets phase timings while an ordinary user
    gets nothing — never emitted on the shipped Hono server. The disclosure gate the
    Hono middleware opens is only ever flipped by the runtime dispatcher's
    timedResolveExecutionContext, but the data (/api/v1/data/*) and metadata
    (/api/v1/meta/*) routes on os serve/dev are served by @objectstack/rest's
    RestServer (which shadows the Hono plugin's own CRUD), and its identity
    resolver never opened the gate. Only global mode (OS_SERVER_TIMING=true) — which
    discloses to every caller, not just admins — worked.

    • observability: the disclosure predicate isPerfDisclosurePrincipal(ec) now
      lives here (the home of the gate), the single definition of "who may pull
      per-request timings" shared by every HTTP entry point. @objectstack/runtime
      re-exports it for back-compat.
    • rest: RestServer.resolveExecCtx opens the gate for an admin/service
      principal (via the carried posture rung), the REST-server analog of the
      dispatcher — this is the fix that makes os serve/dev emit.
    • plugin-hono-server: the standalone CRUD surface's self-contained
      resolveCtx opens the gate too (deriving the rung for the gate decision only,
      never writing it onto the enforcement context). Adds an e2e test that boots the
      Hono app and asserts an admin gets Server-Timing while a member/anon does not.
  • Updated dependencies [9e45b63]

  • Updated dependencies [b20201f]

  • Updated dependencies [818e6a3]

    • @objectstack/spec@16.1.0
    • @objectstack/core@16.1.0
    • @objectstack/observability@16.1.0
    • @objectstack/rest@16.1.0
    • @objectstack/metadata@16.1.0
    • @objectstack/plugin-auth@16.1.0
    • @objectstack/plugin-security@16.1.0
    • @objectstack/formula@16.1.0
    • @objectstack/metadata-core@16.1.0
    • @objectstack/objectql@16.1.0
    • @objectstack/driver-memory@16.1.0
    • @objectstack/driver-sql@16.1.0
    • @objectstack/driver-sqlite-wasm@16.1.0
    • @objectstack/service-cluster@16.1.0
    • @objectstack/service-datasource@16.1.0
    • @objectstack/service-i18n@16.1.0
    • @objectstack/types@16.1.0

@objectstack/service-analytics@16.1.0

Patch Changes

  • Updated dependencies [9e45b63]
  • Updated dependencies [b20201f]
    • @objectstack/spec@16.1.0
    • @objectstack/core@16.1.0

@objectstack/service-cache@16.1.0

Patch Changes

  • Updated dependencies [9e45b63]
  • Updated dependencies [b20201f]
  • Updated dependencies [818e6a3]
    • @objectstack/spec@16.1.0
    • @objectstack/core@16.1.0
    • @objectstack/observability@16.1.0

@objectstack/service-cluster@16.1.0

Patch Changes

  • Updated dependencies [9e45b63]
  • Updated dependencies [b20201f]
    • @objectstack/spec@16.1.0
    • @objectstack/core@16.1.0

@objectstack/service-cluster-redis@16.1.0

Patch Changes

  • Updated dependencies [9e45b63]
    • @objectstack/spec@16.1.0
    • @objectstack/service-cluster@16.1.0

@objectstack/service-datasource@16.1.0

Patch Changes

  • Updated dependencies [9e45b63]
  • Updated dependencies [b20201f]
    • @objectstack/spec@16.1.0
    • @objectstack/core@16.1.0

@objectstack/service-i18n@16.1.0

Patch Changes

  • Updated dependencies [9e45b63]
  • Updated dependencies [b20201f]
    • @objectstack/spec@16.1.0
    • @objectstack/core@16.1.0

@objectstack/service-job@16.1.0

Patch Changes

  • Updated dependencies [212b66a]
  • Updated dependencies [d10c4dc]
  • Updated dependencies [9e45b63]
  • Updated dependencies [b20201f]
    • @objectstack/platform-objects@16.1.0
    • @objectstack/spec@16.1.0
    • @objectstack/core@16.1.0

@objectstack/service-knowledge@16.1.0

Patch Changes

  • Updated dependencies [9e45b63]
  • Updated dependencies [b20201f]
    • @objectstack/spec@16.1.0
    • @objectstack/core@16.1.0

@objectstack/service-messaging@16.1.0

Patch Changes

  • Updated dependencies [9e45b63]
  • Updated dependencies [b20201f]
    • @objectstack/spec@16.1.0
    • @objectstack/core@16.1.0

@objectstack/service-package@16.1.0

Patch Changes

  • Updated dependencies [9e45b63]
  • Updated dependencies [b20201f]
    • @objectstack/spec@16.1.0
    • @objectstack/core@16.1.0
    • @objectstack/metadata-core@16.1.0

@objectstack/service-queue@16.1.0

Patch Changes

  • Updated dependencies [212b66a]
  • Updated dependencies [d10c4dc]
  • Updated dependencies [9e45b63]
  • Updated dependencies [b20201f]
    • @objectstack/platform-objects@16.1.0
    • @objectstack/spec@16.1.0
    • @objectstack/core@16.1.0

@objectstack/service-realtime@16.1.0

Patch Changes

  • Updated dependencies [212b66a]
  • Updated dependencies [d10c4dc]
  • Updated dependencies [9e45b63]
  • Updated dependencies [b20201f]
    • @objectstack/platform-objects@16.1.0
    • @objectstack/spec@16.1.0
    • @objectstack/core@16.1.0

@objectstack/service-settings@16.1.0

Patch Changes

  • Updated dependencies [212b66a]
  • Updated dependencies [d10c4dc]
  • Updated dependencies [9e45b63]
  • Updated dependencies [b20201f]
    • @objectstack/platform-objects@16.1.0
    • @objectstack/spec@16.1.0
    • @objectstack/core@16.1.0
    • @objectstack/types@16.1.0

@objectstack/service-sms@16.1.0

Patch Changes

  • Updated dependencies [9e45b63]
  • Updated dependencies [b20201f]
    • @objectstack/spec@16.1.0
    • @objectstack/core@16.1.0

@objectstack/service-storage@16.1.0

Patch Changes

  • Updated dependencies [212b66a]
  • Updated dependencies [d10c4dc]
  • Updated dependencies [9e45b63]
  • Updated dependencies [b20201f]
  • Updated dependencies [818e6a3]
    • @objectstack/platform-objects@16.1.0
    • @objectstack/spec@16.1.0
    • @objectstack/core@16.1.0
    • @objectstack/observability@16.1.0

@objectstack/trigger-api@16.1.0

Patch Changes

  • Updated dependencies [9e45b63]
  • Updated dependencies [b20201f]
    • @objectstack/spec@16.1.0
    • @objectstack/core@16.1.0

@objectstack/trigger-record-change@16.1.0

Patch Changes

  • b20201f: fix(service-automation): runAs:'user' runs data ops with the triggering user's
    real permission sets + positions, not a bare member fallback (service-automation: runAs:'user' runs data ops with a credential-less user — trigger context never carries the actor's permission sets/positions (follow-up to #1888) #3356, follow-up to
    [P0][security] Flow runAs never switches execution identity #1888)

    Since [P0][security] Flow runAs never switches execution identity #1888 the automation engine honours flow.runAs (system elevates), but
    the runAs:'user' credential propagation was hollow. A record-change-triggered
    runAs:'user' flow ran its data nodes (update_record, …) with a zero-grant
    principal — only the member/everyone baseline — even when the triggering user
    was fully authorized. Two faces by object config: a private object 403'd the
    in-flow write (not permitted for positions [org_member, everyone] — the user's
    permission sets were invisible); a public_read_write object let the write
    through but silently stripped readonly/FLS-gated fields. The root cause: the
    ObjectQL record-change hook session carries only a userId — never the writer's
    positions/permission sets — and nothing in between resolved them, so the comment
    promising "enforces RLS exactly as the user who made the change" never held.

    The fix resolves the triggering user's actual authorization at run setup, from
    the same tables a direct REST request resolves through:

    • @objectstack/core factors the userId-driven core of resolveAuthzContext
      into a new exported resolveUserAuthzGrants(ql, userId, opts) — the single place
      that reads sys_member / sys_user_position / sys_*_permission_set and
      derives positions, permission-set names, platform_admin, and posture. The
      HTTP resolver now delegates to it (behaviour byte-identical; the full contract
      suite still passes), so a non-HTTP surface that already knows the user id builds
      the SAME envelope instead of re-implementing the reads.
    • @objectstack/service-automation gains AutomationEngine.setUserGrantsResolver,
      wired by the plugin to resolveUserAuthzGrants over the objectql/data engine.
      For a runAs:'user' run whose trigger left the authz envelope unresolved (no
      permissions), the engine now resolves the user's positions + permission sets
      once at run setup and threads them into every data node's ObjectQL context —
      so the run enforces RLS/FLS exactly as that user. Contexts that already carry
      permissions are left untouched (a REST trigger, and notably an ADR-0090 agent
      ceiling acting on-behalf-of a user — always non-empty — so a deliberately
      narrowed identity is never re-broadened). runAs:'system' is unchanged, and a
      resolver error fails safe (warns, keeps the bare user — never elevates).
    • @objectstack/trigger-record-change stops forwarding the misleading
      half-populated positions (empty in practice, and never permissions) from the
      hook session; it forwards userId + tenant only and lets the engine resolve the
      full grants authoritatively.

    When no ObjectQL engine is present (bare engine / tests) the resolver is unwired
    and run identity is unchanged from before.

  • Updated dependencies [9e45b63]

  • Updated dependencies [b20201f]

    • @objectstack/spec@16.1.0
    • @objectstack/core@16.1.0

@objectstack/trigger-schedule@16.1.0

Patch Changes

  • Updated dependencies [9e45b63]
  • Updated dependencies [b20201f]
    • @objectstack/spec@16.1.0
    • @objectstack/core@16.1.0

@objectstack/types@16.1.0

Patch Changes

  • Updated dependencies [9e45b63]
    • @objectstack/spec@16.1.0

@objectstack/verify@16.1.0

Patch Changes

  • Updated dependencies [9e45b63]
  • Updated dependencies [b20201f]
  • Updated dependencies [818e6a3]
    • @objectstack/spec@16.1.0
    • @objectstack/core@16.1.0
    • @objectstack/service-automation@16.1.0
    • @objectstack/rest@16.1.0
    • @objectstack/plugin-hono-server@16.1.0
    • @objectstack/runtime@16.1.0
    • @objectstack/plugin-auth@16.1.0
    • @objectstack/plugin-security@16.1.0
    • @objectstack/plugin-sharing@16.1.0
    • @objectstack/service-settings@16.1.0
    • @objectstack/objectql@16.1.0
    • @objectstack/driver-sqlite-wasm@16.1.0
    • @objectstack/service-analytics@16.1.0
    • @objectstack/service-datasource@16.1.0

create-objectstack@16.1.0

@objectstack/sdui-parser@16.1.0

objectstack-vscode@16.1.0

@objectstack/example-crm@4.0.91

Patch Changes

  • Updated dependencies [9e45b63]
  • Updated dependencies [818e6a3]
    • @objectstack/spec@16.1.0
    • @objectstack/runtime@16.1.0

@objectstack/example-showcase@0.3.13

Patch Changes

  • Updated dependencies [9e45b63]
  • Updated dependencies [818e6a3]
    • @objectstack/spec@16.1.0
    • @objectstack/runtime@16.1.0
    • @objectstack/cloud-connection@16.1.0
    • @objectstack/connector-mcp@16.1.0
    • @objectstack/connector-openapi@16.1.0
    • @objectstack/connector-rest@16.1.0
    • @objectstack/connector-slack@16.1.0
    • @objectstack/driver-sql@16.1.0
    • @objectstack/service-datasource@16.1.0

@objectstack/example-todo@4.0.91

Patch Changes

  • Updated dependencies [9e45b63]
  • Updated dependencies [818e6a3]
    • @objectstack/spec@16.1.0
    • @objectstack/runtime@16.1.0
    • @objectstack/metadata@16.1.0
    • @objectstack/client@16.1.0
    • @objectstack/mcp@16.1.0
    • @objectstack/objectql@16.1.0
    • @objectstack/driver-sqlite-wasm@16.1.0
    • @objectstack/knowledge-memory@16.1.0
    • @objectstack/service-knowledge@16.1.0

@objectstack/example-embed-objectql@0.0.31

Patch Changes

  • Updated dependencies [9e45b63]
    • @objectstack/spec@16.1.0
    • @objectstack/objectql@16.1.0
    • @objectstack/driver-memory@16.1.0

@objectstack/dogfood@0.0.39

Patch Changes

  • Updated dependencies [9e45b63]
    • @objectstack/spec@16.1.0
    • @objectstack/plugin-audit@16.1.0
    • @objectstack/plugin-auth@16.1.0
    • @objectstack/plugin-security@16.1.0
    • @objectstack/service-storage@16.1.0
    • @objectstack/example-crm@4.0.91
    • @objectstack/example-showcase@0.3.13
    • @objectstack/connector-mcp@16.1.0
    • @objectstack/connector-openapi@16.1.0
    • @objectstack/connector-rest@16.1.0
    • @objectstack/mcp@16.1.0
    • @objectstack/objectql@16.1.0
    • @objectstack/verify@16.1.0

@objectstack/downstream-contract@0.0.37

Patch Changes

  • Updated dependencies [9e45b63]
    • @objectstack/spec@16.1.0

@objectstack/http-conformance@0.0.5

Patch Changes

  • Updated dependencies [b20201f]
    • @objectstack/core@16.1.0

@vercel

vercel Bot commented Jul 21, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
spec Ready Ready Preview, Comment Jul 22, 2026 12:30am

Request Review

@github-actions
github-actions Bot force-pushed the changeset-release/main branch from cd6121b to 71f2c63 Compare July 21, 2026 14:15
@github-actions
github-actions Bot force-pushed the changeset-release/main branch 2 times, most recently from b9d79bc to 29551e8 Compare July 21, 2026 14:39
@github-actions
github-actions Bot force-pushed the changeset-release/main branch from 29551e8 to 5d8ea00 Compare July 21, 2026 15:02
@github-actions
github-actions Bot force-pushed the changeset-release/main branch from 5d8ea00 to 122798f Compare July 21, 2026 15:12
@github-actions
github-actions Bot force-pushed the changeset-release/main branch from 122798f to eba7196 Compare July 21, 2026 15:22
@github-actions
github-actions Bot force-pushed the changeset-release/main branch 2 times, most recently from 6e7b185 to 10462e5 Compare July 21, 2026 15:39
@github-actions
github-actions Bot force-pushed the changeset-release/main branch 3 times, most recently from a3ac5a8 to 6c4be0f Compare July 21, 2026 16:11
@github-actions
github-actions Bot force-pushed the changeset-release/main branch from 6c4be0f to ed5c0a3 Compare July 21, 2026 16:21
@github-actions
github-actions Bot force-pushed the changeset-release/main branch from ed5c0a3 to 6ec6ac0 Compare July 21, 2026 16:40
@github-actions
github-actions Bot force-pushed the changeset-release/main branch from 6ec6ac0 to 21933cf Compare July 22, 2026 00:05
@github-actions
github-actions Bot force-pushed the changeset-release/main branch from 21933cf to f3ce1f2 Compare July 22, 2026 00:27
@os-zhuang
os-zhuang merged commit 76f18c2 into main Jul 22, 2026
3 checks passed
@os-zhuang
os-zhuang deleted the changeset-release/main branch July 22, 2026 00:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant