chore: release packages#2624
Open
github-actions[bot] wants to merge 1 commit into
Open
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
github-actions
Bot
force-pushed
the
changeset-release/main
branch
11 times, most recently
from
July 17, 2026 12:59
38ffe76 to
6c10781
Compare
github-actions
Bot
force-pushed
the
changeset-release/main
branch
from
July 17, 2026 14:50
6c10781 to
1813289
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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
@object-ui/types@16.0.0
Major Changes
9b8f978: Adopt
@objectstack/spec15 across the workspace and drop the value-erased…Schemare-exports from@object-ui/types(@object-ui/types: decide the@objectstack/spec/uire-export shape + bump spec pin to ^15 #2561).Removed exports.
packages/typesre-exported the@objectstack/spec/uisurface insideexport type { … }blocks, and those blocks included the zod validators (DndConfigSchema,SpecFormViewSchema,ThemeModeSchema, … 84 names in total). Underexport typea zod value is erased, so importing any of them as a value from@object-ui/typessilently yieldedundefinedat runtime. Per the @object-ui/types: decide the@objectstack/spec/uire-export shape + bump spec pin to ^15 #2561 decision (option a) the schema names are removed from the public surface instead of being converted to value re-exports — consumers that need the runtime validators import them from@objectstack/spec/uidirectly. The inferred types (DndConfig,SpecFormView, …) are unchanged, and the genuine value re-exports (defineStack,ObjectStackSchema,SpecReportSchema, …) keep working.BreakpointColumnMapSchema/BreakpointOrderMapSchemaare dropped without a type replacement (the spec exports no companion inferred type). A guardrail test (spec-ui-schema-reexports.test.ts) pins the contract.Spec 15. Every workspace package now depends on
@objectstack/spec^15.1.1. The/uiexport-name set is identical to 14.6; the spec-level breaking change is ADR-0089 D3a —FormFieldSchema/FormSectionSchema/PageComponentSchemaare.strict()and reject undeclared keys, which the workspace test suite passes under. The floor is 15.1.1 (not 15.0.0) because D3a's.strict().transform(…)pipes crashedz.toJSONSchemaover spec's lazySchema proxies (Cannot set properties of undefined (setting 'ref')), breaking Studio's spec-derived Page/View inspector schemas; fixed upstream in framework#3021, which shipped in spec 15.1.1. Newview-schema.test.tspins the View-inspector derivation (previously untested — it degraded silently).Minor Changes
b4ef588: feat(types): derive
ListViewSchemafrom@objectstack/spec/uiinstead of a hand-written copy (Unify hand-written @object-ui/types zod with @objectstack/spec/ui (ListViewSchema drift) #2231)@object-ui/typesshipped a hand-written mirror of the spec's UI ListView zod(
packages/types/src/zod/objectql.zod.ts) plus a parallel hand-written TSinterface(
objectql.ts). Both had drifted from the authoritative@objectstack/spec/uiListViewSchema, with nothing enforcing they stay in sync.ListViewSchemanow derives from the spec'sListViewSchema: spec-ownedfields (
filter,sort,selection,navigation,pagination,grouping,rowColor,userActions,appearance,tabs,addRecord,rowHeight,sharing,chart/treeconfigs,responsive,performance, …) flow in by reference insteadof being re-typed. The component envelope (
type: 'list-view'discriminator +objectName) and the legacy objectui vocabulary (viewType,fields,filters, theshow*toolbar flags,densityMode,color, …) plus the configs whose objectui shapeis intentionally broader than spec's (
userFilters,sharing,aria,conditionalFormatting,exportOptions,kanban/calendar/gantt/gallery/timeline) remain as sanctioned local.extend()s. Existing payloads keep validating;spec-canonical payloads (
columns/filter/userActions) now validate too.interface ListViewSchemais replaced byz.infer<typeof ListViewSchema> & ListViewRuntimeProps, so the type can no longer driftfrom the schema. Non-serializable runtime-only props (
onNavigate,onDensityChange,refreshTrigger) live inListViewRuntimeProps.list-view-spec-parity.test.ts) that fails if the spec grows afield objectui hasn't triaged, renames an aliased anchor (
type/columns/filter), oran objectui-only field is added outside the sanctioned-local set.
@objectstack/specdependency^14.6.0→^15.1.0across the workspace(15.1.0 carries the framework#3021
lazySchema/z.toJSONSchemaidentity fix that thespec-derived Page/View inspectors depend on).
Migrating the legacy vocabulary to the spec-canonical keys and adopting spec's narrower
sub-shapes are deferred follow-ups (see Unify hand-written @object-ui/types zod with @objectstack/spec/ui (ListViewSchema drift) #2231). No runtime behavior change.
5534535: feat(grid): built-in row Edit/Delete honor per-record CEL predicates (Row CRUD actions (Edit/Delete) should support per-record visible/disabled CEL predicates #2614)
The object's
userActions.edit/userActions.deletenow also accept anobject form
{ enabled?, visibleWhen?, disabledWhen? }. The predicates areevaluated per row on the canonical CEL engine (
useRowPredicate, the samemachinery custom row actions use):
visibleWhenfalse → the built-inEdit/Delete item is not rendered for that row (fail-closed);
disabledWhentrue → rendered disabled (fail-soft). Wired through ObjectGrid's
RowActionMenu and the data-table's row overflow menu (the related-list
path), with the app-shell
crudAffordancesmirror kept in lockstep.Omitting the predicates (or using plain booleans) keeps today's behavior
bit-for-bit; declared predicates evaluate only when a row's menu opens, so
grid rendering cost is unchanged.
@object-ui/app-shell@16.0.0
Minor Changes
d3e19ed: Adapt to framework 15.1: (1) ADR-0067 D2 all-or-nothing publishes —
formatPublishFailuresrenders a rolled-back batch as ONE banner anchored on the causal item (batch_abortedentries are summarized, not listed as parallel errors); PackagesPage says "rolled back because X" instead of "{n} failed"; the AI chat publish toast surfaces the real reason instead of a bare count. Pre-15.1 partial-publish responses keep their per-item rendering. (2) ADR-0076 D12 honest discovery —DiscoveryServiceStatusgainshandlerReady+degraded/stubstatuses, new backward-tolerantisServiceUsable()helper (absent fields keep the pre-15.1 default;stub/handlerReady:falsegate off;degradedstays usable), consumed byisAuthEnabled/isAiEnabledandConditionalAuthWrapper.5534535: feat(grid): built-in row Edit/Delete honor per-record CEL predicates (Row CRUD actions (Edit/Delete) should support per-record visible/disabled CEL predicates #2614)
The object's
userActions.edit/userActions.deletenow also accept anobject form
{ enabled?, visibleWhen?, disabledWhen? }. The predicates areevaluated per row on the canonical CEL engine (
useRowPredicate, the samemachinery custom row actions use):
visibleWhenfalse → the built-inEdit/Delete item is not rendered for that row (fail-closed);
disabledWhentrue → rendered disabled (fail-soft). Wired through ObjectGrid's
RowActionMenu and the data-table's row overflow menu (the related-list
path), with the app-shell
crudAffordancesmirror kept in lockstep.Omitting the predicates (or using plain booleans) keeps today's behavior
bit-for-bit; declared predicates evaluate only when a row's menu opens, so
grid rendering cost is unchanged.
Patch Changes
c0bd483: Plan-card approval gives immediate in-card feedback (fix(ai): 构建方案确认后 ~10s 无中间反馈;随后对话历史短暂整体清空(状态 race) #2627): clicking
"Build it" flips the clicked card to a spinning "Building…" badge right away
(the approval's chat-level effects land at the bottom of the thread, outside
the viewport, so the card looked untouched for ~10s and users double-clicked).
The durable Built state still derives from the message stream; an approval
that never left the client (rate limit / offline) rolls the badge back so the
button returns. New
planBuildingLabelprop (AiChatPage passes zh).59d4fa9: fix(detail): show the "Locked for approval" band on request-tracked backends (objectui#2618)
The DetailView approval-lock band keyed only off the record's own
approval_statusfield, so it never rendered on backends that track the lockvia an open approval request and never materialize that field — even though
the lock was real (writes rejected with
RECORD_LOCKED). The record-levelInlineEditContextnow carries the host'slocked/lockedReasonsignal(the same dual-source
approvalLockedthat already gatescanEditinRecordDetailView), and the band renders from it while keepingDetailViewDataSource-agnostic. Also backfills the approval-lock strings into the detail
translation defaults so a bare DetailView shows the label, not the raw i18n key.
33b4995: Welcome-page "Create your environment" deep-links straight into the create
dialog (feat: URL-driven debug/developer panel (à la amis devtools) #844):
action:buttongains a client-sideautoTriggerflag (runsthe action once on mount — same execute path as a click, so param dialogs /
confirms / entitlement gates still apply), and the environments list consumes
?runAction=create_environmentto mark its create action once entitlementsresolve (upgrade-locked orgs get the upgrade prompt instead; the param is
stripped after consumption so refresh/back don't re-open). Also localizes the
EnvironmentListToolbar's state-aware label overrides ({en,zh}) — they were
hard-coded English inside a zh console.
Updated dependencies [d3e19ed]
Updated dependencies [c0bd483]
Updated dependencies [59d4fa9]
Updated dependencies [4c7c47f]
Updated dependencies [b4ef588]
Updated dependencies [45c6fb4]
Updated dependencies [ca0f5f0]
Updated dependencies [077e45b]
Updated dependencies [022735f]
Updated dependencies [5534535]
Updated dependencies [9b8f978]
Updated dependencies [195a651]
Updated dependencies [33b4995]
@object-ui/components@16.0.0
Minor Changes
5534535: feat(grid): built-in row Edit/Delete honor per-record CEL predicates (Row CRUD actions (Edit/Delete) should support per-record visible/disabled CEL predicates #2614)
The object's
userActions.edit/userActions.deletenow also accept anobject form
{ enabled?, visibleWhen?, disabledWhen? }. The predicates areevaluated per row on the canonical CEL engine (
useRowPredicate, the samemachinery custom row actions use):
visibleWhenfalse → the built-inEdit/Delete item is not rendered for that row (fail-closed);
disabledWhentrue → rendered disabled (fail-soft). Wired through ObjectGrid's
RowActionMenu and the data-table's row overflow menu (the related-list
path), with the app-shell
crudAffordancesmirror kept in lockstep.Omitting the predicates (or using plain booleans) keeps today's behavior
bit-for-bit; declared predicates evaluate only when a row's menu opens, so
grid rendering cost is unchanged.
Patch Changes
4c7c47f: fix(form): thread live
dependentValuesto cascading option fields (表单支持级联/依赖选项:新增 SelectOption.visibleWhen 通用谓词 #2284/B3: dynamic field options / cascading selects (option.visibleWhen) — remaining: server enforcement, live e2e, ADR #1583)The form renderer only injected the live form record into data-source widgets
(
lookup/master_detail/… — theDATA_SOURCE_FIELD_TYPESset). Registeredoption widgets (
field:select/field:radio/field:multiselect) that carryper-option
visibleWhen+dependsOncascading were excluded, sostripRegisteredFieldPropsdroppeddependentValuesbefore it reachedSelectField. With no live record and noformValuescontext fallback, acascading
selectnever saw its controlling field: in a create form thedependent field stayed permanently gated on the "Select the parent first" hint
even after the parent was chosen (reproduced on the showcase
showcase_cascadeB3 fixture — country → province never unlocked).
Option field types now receive
dependentValuestoo, so the widget'sdependsOngate lifts and itsvisibleWhenset re-filters live as the parentchanges — the same channel the lookup fix (Cascading lookup (dependsOn) broken in forms: stays gated after parent is chosen; table picker bypasses the dependent filter #2215/fix(fields): unlock dependent lookups on parent selection and enforce the cascade on every picker #2216) already used. Regression
guard added in
form-dependent-values.test.tsx(drives the registeredfield:selectpath, not just the builtincase 'select'fallback the priorcascading-select test covered).
33b4995: Welcome-page "Create your environment" deep-links straight into the create
dialog (feat: URL-driven debug/developer panel (à la amis devtools) #844):
action:buttongains a client-sideautoTriggerflag (runsthe action once on mount — same execute path as a click, so param dialogs /
confirms / entitlement gates still apply), and the environments list consumes
?runAction=create_environmentto mark its create action once entitlementsresolve (upgrade-locked orgs get the upgrade prompt instead; the param is
stripped after consumption so refresh/back don't re-open). Also localizes the
EnvironmentListToolbar's state-aware label overrides ({en,zh}) — they were
hard-coded English inside a zh console.
Updated dependencies [d3e19ed]
Updated dependencies [59d4fa9]
Updated dependencies [b4ef588]
Updated dependencies [ca0f5f0]
Updated dependencies [5534535]
Updated dependencies [9b8f978]
Updated dependencies [195a651]
@object-ui/plugin-detail@16.0.0
Minor Changes
5534535: feat(grid): built-in row Edit/Delete honor per-record CEL predicates (Row CRUD actions (Edit/Delete) should support per-record visible/disabled CEL predicates #2614)
The object's
userActions.edit/userActions.deletenow also accept anobject form
{ enabled?, visibleWhen?, disabledWhen? }. The predicates areevaluated per row on the canonical CEL engine (
useRowPredicate, the samemachinery custom row actions use):
visibleWhenfalse → the built-inEdit/Delete item is not rendered for that row (fail-closed);
disabledWhentrue → rendered disabled (fail-soft). Wired through ObjectGrid's
RowActionMenu and the data-table's row overflow menu (the related-list
path), with the app-shell
crudAffordancesmirror kept in lockstep.Omitting the predicates (or using plain booleans) keeps today's behavior
bit-for-bit; declared predicates evaluate only when a row's menu opens, so
grid rendering cost is unchanged.
Patch Changes
59d4fa9: fix(detail): show the "Locked for approval" band on request-tracked backends (objectui#2618)
The DetailView approval-lock band keyed only off the record's own
approval_statusfield, so it never rendered on backends that track the lockvia an open approval request and never materialize that field — even though
the lock was real (writes rejected with
RECORD_LOCKED). The record-levelInlineEditContextnow carries the host'slocked/lockedReasonsignal(the same dual-source
approvalLockedthat already gatescanEditinRecordDetailView), and the band renders from it while keepingDetailViewDataSource-agnostic. Also backfills the approval-lock strings into the detail
translation defaults so a bare DetailView shows the label, not the raw i18n key.
Updated dependencies [d3e19ed]
Updated dependencies [59d4fa9]
Updated dependencies [4c7c47f]
Updated dependencies [b4ef588]
Updated dependencies [ca0f5f0]
Updated dependencies [5534535]
Updated dependencies [9b8f978]
Updated dependencies [195a651]
Updated dependencies [33b4995]
@object-ui/plugin-grid@16.0.0
Minor Changes
5534535: feat(grid): built-in row Edit/Delete honor per-record CEL predicates (Row CRUD actions (Edit/Delete) should support per-record visible/disabled CEL predicates #2614)
The object's
userActions.edit/userActions.deletenow also accept anobject form
{ enabled?, visibleWhen?, disabledWhen? }. The predicates areevaluated per row on the canonical CEL engine (
useRowPredicate, the samemachinery custom row actions use):
visibleWhenfalse → the built-inEdit/Delete item is not rendered for that row (fail-closed);
disabledWhentrue → rendered disabled (fail-soft). Wired through ObjectGrid's
RowActionMenu and the data-table's row overflow menu (the related-list
path), with the app-shell
crudAffordancesmirror kept in lockstep.Omitting the predicates (or using plain booleans) keeps today's behavior
bit-for-bit; declared predicates evaluate only when a row's menu opens, so
grid rendering cost is unchanged.
Patch Changes
@object-ui/react@16.0.0
Minor Changes
formatPublishFailuresrenders a rolled-back batch as ONE banner anchored on the causal item (batch_abortedentries are summarized, not listed as parallel errors); PackagesPage says "rolled back because X" instead of "{n} failed"; the AI chat publish toast surfaces the real reason instead of a bare count. Pre-15.1 partial-publish responses keep their per-item rendering. (2) ADR-0076 D12 honest discovery —DiscoveryServiceStatusgainshandlerReady+degraded/stubstatuses, new backward-tolerantisServiceUsable()helper (absent fields keep the pre-15.1 default;stub/handlerReady:falsegate off;degradedstays usable), consumed byisAuthEnabled/isAiEnabledandConditionalAuthWrapper.Patch Changes
59d4fa9: fix(detail): show the "Locked for approval" band on request-tracked backends (objectui#2618)
The DetailView approval-lock band keyed only off the record's own
approval_statusfield, so it never rendered on backends that track the lockvia an open approval request and never materialize that field — even though
the lock was real (writes rejected with
RECORD_LOCKED). The record-levelInlineEditContextnow carries the host'slocked/lockedReasonsignal(the same dual-source
approvalLockedthat already gatescanEditinRecordDetailView), and the band renders from it while keepingDetailViewDataSource-agnostic. Also backfills the approval-lock strings into the detail
translation defaults so a bare DetailView shows the label, not the raw i18n key.
195a651: refactor(spec-bridge): retire the hand-written
ListViewSpec/ListColumnmirrors in the list-view bridge (Unify hand-written @object-ui/types zod with @objectstack/spec/ui (ListViewSchema drift) #2231 follow-up)The SpecBridge's list-view bridge kept a third hand-written copy of the ListView shape
(after the zod schema and the TS interface unified in the previous Unify hand-written @object-ui/types zod with @objectstack/spec/ui (ListViewSchema drift) #2231 PR). It now
derives its input type from
@objectstack/spec/ui(Partial<ListView>, specListColumn),so the bridge can no longer drift from the protocol.
Behavior fix surfaced by the real types: spec
columnsisstring[] | ListColumn[], butthe old local interface only admitted
ListColumn[]— a bare field-name column would haveproduced a broken
{ accessorKey: undefined }mapping. String columns now map to a defaultcolumn (
{ accessorKey: field, header: field }).Updated dependencies [b4ef588]
Updated dependencies [ca0f5f0]
Updated dependencies [5534535]
Updated dependencies [9b8f978]
@object-ui/console@16.0.0
Patch Changes
admin@objectos.aion an empty development database, but nothing on the login page said so — new users clicked "Sign up" and landed in an empty non-admin workspace (15.1 third-party eval). WhenGET /api/v1/auth/configreportsdevSeedAdmin(dev-only; the server omits the field in production and once the default password is changed), the page renders a dismissible amber banner with the credentials. Dismissal persists per browser via localStorage.@object-ui/auth@16.0.0
Patch Changes
45c6fb4: Login-page auth-config hardening (fix(auth): env 登录页首次加载缺 SSO 按钮 — auth config race 让 SSO-only 用户卡死在密码墙 #2625, fix(auth): SSO 按钮点击后请求挂死时永久转圈 — pending 态缺超时/错误兜底 #2626):
createAuthClient.getConfignow single-flights + caches the/auth/configfetch (the login page's three consumers used to fire three requests) and
retries failures with backoff (500ms/1.5s/3.5s, 8s per-attempt abort) before
rejecting. A cold-starting environment kernel no longer strands the page
without its SSO buttons; a final failure clears the cache so later callers
retry.
LoginFormholds a spinner instead of painting the password-form defaultswhile config resolves — an SSO-only deployment must never flash a password
wall at JIT users who have no password. A failed config still falls back to
the password form (break-glass beats lock-out).
signInWithProvidergains a 20s watchdog: a sign-in request that hangs nowrejects with a clear timeout error so the provider button recovers instead
of spinning forever.
renders its own, and the stacked pair read as a rendering glitch.
077e45b:
signInWithProviderwithtype: 'oidc'now signs in through better-auth'score social route (
POST /sign-in/social) and only falls back to the legacyPOST /sign-in/oauth2endpoint when the social route rejects the provider.better-auth ≥ 1.7 restructured the
genericOAuthplugin: generic OAuth/OIDCproviders are injected into the core social sign-in flow and the dedicated
/sign-in/oauth2endpoint no longer exists. The old client therefore 404'd onevery "Continue with ObjectStack" click (platform SSO broken end-to-end on
current framework). The fallback keeps the button working against older
(< 1.7) servers during the coordinated rollout; when both routes fail, the
social-route error is surfaced since on a ≥ 1.7 server it is the real failure.
022735f: RegisterForm: drop the duplicate "or" divider (matching the LoginForm fix in
fix(auth): login-page config race + sign-in watchdog — never strand SSO-only users on a password wall #2629). SocialSignInButtons already renders its own "or continue with email"
divider under the provider buttons; RegisterForm stacked a second "OR" line on
top, which read as a rendering glitch on the sign-up page.
Updated dependencies [b4ef588]
Updated dependencies [5534535]
Updated dependencies [9b8f978]
@object-ui/cli@16.0.0
Patch Changes
@object-ui/collaboration@16.0.0
Patch Changes
@object-ui/core@16.0.0
Patch Changes
@object-ui/data-objectstack@16.0.0
Patch Changes
@object-ui/fields@16.0.0
Patch Changes
@object-ui/i18n@16.0.0
Patch Changes
admin@objectos.aion an empty development database, but nothing on the login page said so — new users clicked "Sign up" and landed in an empty non-admin workspace (15.1 third-party eval). WhenGET /api/v1/auth/configreportsdevSeedAdmin(dev-only; the server omits the field in production and once the default password is changed), the page renders a dismissible amber banner with the credentials. Dismissal persists per browser via localStorage.@object-ui/layout@16.0.0
Patch Changes
@object-ui/mobile@16.0.0
Patch Changes
@object-ui/permissions@16.0.0
Patch Changes
@object-ui/plugin-ai@16.0.0
Patch Changes
@object-ui/plugin-calendar@16.0.0
Patch Changes
@object-ui/plugin-charts@16.0.0
Patch Changes
@object-ui/plugin-chatbot@16.0.0
Patch Changes
"Build it" flips the clicked card to a spinning "Building…" badge right away
(the approval's chat-level effects land at the bottom of the thread, outside
the viewport, so the card looked untouched for ~10s and users double-clicked).
The durable Built state still derives from the message stream; an approval
that never left the client (rate limit / offline) rolls the badge back so the
button returns. New
planBuildingLabelprop (AiChatPage passes zh).@object-ui/plugin-dashboard@16.0.0
Patch Changes
@object-ui/plugin-designer@16.0.0
Patch Changes
@object-ui/plugin-editor@16.0.0
Patch Changes
@object-ui/plugin-form@16.0.0
Patch Changes
5534535: feat(grid): built-in row Edit/Delete honor per-record CEL predicates (Row CRUD actions (Edit/Delete) should support per-record visible/disabled CEL predicates #2614)
The object's
userActions.edit/userActions.deletenow also accept anobject form
{ enabled?, visibleWhen?, disabledWhen? }. The predicates areevaluated per row on the canonical CEL engine (
useRowPredicate, the samemachinery custom row actions use):
visibleWhenfalse → the built-inEdit/Delete item is not rendered for that row (fail-closed);
disabledWhentrue → rendered disabled (fail-soft). Wired through ObjectGrid's
RowActionMenu and the data-table's row overflow menu (the related-list
path), with the app-shell
crudAffordancesmirror kept in lockstep.Omitting the predicates (or using plain booleans) keeps today's behavior
bit-for-bit; declared predicates evaluate only when a row's menu opens, so
grid rendering cost is unchanged.
Updated dependencies [d3e19ed]
Updated dependencies [59d4fa9]
Updated dependencies [4c7c47f]
Updated dependencies [b4ef588]
Updated dependencies [ca0f5f0]
Updated dependencies [5534535]
Updated dependencies [9b8f978]
Updated dependencies [195a651]
Updated dependencies [33b4995]
@object-ui/plugin-gantt@16.0.0
Patch Changes
@object-ui/plugin-kanban@16.0.0
Patch Changes
@object-ui/plugin-list@16.0.0
Patch Changes
@object-ui/plugin-map@16.0.0
Patch Changes
@object-ui/plugin-markdown@16.0.0
Patch Changes
@object-ui/plugin-report@16.0.0
Patch Changes
@object-ui/plugin-timeline@16.0.0
Patch Changes
@object-ui/plugin-tree@16.0.0
Patch Changes
@object-ui/plugin-view@16.0.0
Patch Changes
@object-ui/providers@16.0.0
Patch Changes
@object-ui/runner@16.0.0
Patch Changes
@object-ui/create-plugin@16.0.0
@object-ui/react-runtime@16.0.0
@object-ui/sdui-parser@16.0.0
object-ui@16.0.0
Patch Changes