Repository navigation
chore: version packages - #1969
Closed
github-actions[bot] wants to merge 1 commit into
Closed
github-actions[bot] wants to merge 1 commit into
github-actions[bot] wants to merge 1 commit into
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
github-actions
Bot
force-pushed
the
changeset-release/main
branch
2 times, most recently
from
June 16, 2026 15:47
db7af3f to
853a8bb
Compare
github-actions
Bot
force-pushed
the
changeset-release/main
branch
from
June 16, 2026 15:56
853a8bb to
3a4eeef
Compare
github-actions
Bot
force-pushed
the
changeset-release/main
branch
2 times, most recently
from
June 16, 2026 16:13
faafee3 to
f336a3b
Compare
github-actions
Bot
force-pushed
the
changeset-release/main
branch
from
June 16, 2026 16:22
f336a3b to
52a8718
Compare
os-zhuang
added a commit
that referenced
this pull request
Jun 24, 2026
feat(gantt): configurable 白班/夜班 shift segmentation (排班日) (#1969) objectui@35487eaae8957063d78332c1e3237cd0dd9b2ad9
13 tasks done
This branch was previously deployed
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
@objectstack/cli@9.9.0
Minor Changes
97ecfdd: feat(cli): lint
metadatadoc embeds (ADR-0051 P1) — validate everymetadatafence body shape (type ∈ state_machine | flow | permission with did-you-mean, required name, object required for state_machine) and its same-package reference liveness (the referenced object + state_machine rule / flow / permission set must exist in the stack). A dead same-package reference is a build error, matchingdocs/broken-link.90108e0: feat(cli): liveness author-warning lint — close the spec-liveness loop on the author side.
The liveness ledgers already classify every authorable property live/experimental/dead with evidence, and the CI gate enforces classification completeness — but that knowledge never reached the person (very often an AI) writing the metadata. The new
compilelint (lint-liveness-properties.ts) reads the ledgers and emits an advisory warning when an authored object/field sets a property that is misleading at runtime — e.g.object.enable.feeds(no feed runtime; comments live on sys_comment),object.versioning(no versioning engine),field.columnName(driver ignores it; column == field key),field.maxRating/vectorConfig(renderer reads a different key) — each with a corrective hint toward the supported alternative. Never fails the build (advisory only), consistent with the existing flow anti-pattern lint.Signal-over-noise by design: warnings are opt-in per ledger entry via a new
authorWarn/authorHintannotation (plusexperimentalentries warn by default). Booleans warn only when set truthy, and onlydefault(false)flags are marked, so schema defaults (enable.trash,enable.searchable) never trip it. Coverage grows by annotating more ledger entries, not by changing lint code; today it coversobject(incl.enable.*) andfield.@objectstack/spec: ledger entries gain optionalauthorWarn/authorHint;liveness/is now shipped in the packagefilesso the CLI can read it. Seeded annotations on the misleading object capability flags + aspirational blocks and the misleading dead field props. No schema/runtime change.Patch Changes
@objectstack/objectql@9.9.0
Minor Changes
44c5348: fix: two runtime gaps found by driving the CRM example end-to-end.
Delete of a parent with a required-FK child no longer fails with a misleading " is required" error.
cascadeDeleteRelationsdefaulted alookupFK toset_null; for a required FK that issued an UPDATE clearing the column, which the child's validator rejected with a400 "<field> is required"naming a field that isn't even on the object being deleted (e.g. deleting acrm_accountwith opportunities →"account is required"). A required FK can't be nulled, so a defaultedset_nullnow escalates torestrict: the delete is refused with a clear409 DELETE_RESTRICTEDcarrying the dependent object + count ("Cannot delete crm_account (…): 4 dependent crm_opportunity record(s) reference it via account … set deleteBehavior:'cascade'"). Explicitcascade/restrictand optional (nullable) lookups are unchanged.Removed the hardcoded
POST /data/lead/:id/convertendpoint +convertLeadprotocol method. It hardcoded bare object names (lead/account/contact/opportunity) and a fixed Salesforce field mapping into the framework runtime, so it was unreachable by any real (namespaced) app —/data/crm_lead/:id/convert404s, and the literalleadobject doesn't exist. Lead conversion is an app concern modeled correctly as a flow (the CRM ships acrm_convert_lead_wizardscreen flow); baking a CRM-specific workflow into the framework was false surface. Untested, undocumented, unused by the example. Removed.Patch Changes
@objectstack/rest@9.9.0
Minor Changes
44c5348: fix: two runtime gaps found by driving the CRM example end-to-end.
Delete of a parent with a required-FK child no longer fails with a misleading " is required" error.
cascadeDeleteRelationsdefaulted alookupFK toset_null; for a required FK that issued an UPDATE clearing the column, which the child's validator rejected with a400 "<field> is required"naming a field that isn't even on the object being deleted (e.g. deleting acrm_accountwith opportunities →"account is required"). A required FK can't be nulled, so a defaultedset_nullnow escalates torestrict: the delete is refused with a clear409 DELETE_RESTRICTEDcarrying the dependent object + count ("Cannot delete crm_account (…): 4 dependent crm_opportunity record(s) reference it via account … set deleteBehavior:'cascade'"). Explicitcascade/restrictand optional (nullable) lookups are unchanged.Removed the hardcoded
POST /data/lead/:id/convertendpoint +convertLeadprotocol method. It hardcoded bare object names (lead/account/contact/opportunity) and a fixed Salesforce field mapping into the framework runtime, so it was unreachable by any real (namespaced) app —/data/crm_lead/:id/convert404s, and the literalleadobject doesn't exist. Lead conversion is an app concern modeled correctly as a flow (the CRM ships acrm_convert_lead_wizardscreen flow); baking a CRM-specific workflow into the framework was false surface. Untested, undocumented, unused by the example. Removed.Patch Changes
@objectstack/service-automation@9.9.0
Minor Changes
6bec07e: feat(automation): object-form screen-flow steps
A
screennode that declaresconfig.objectNamenow renders the named object'sFULL create/edit form (including inline master-detail child grids) instead of a
flat field list. The node emits an
object-formScreenSpec(
kind/objectName/mode/recordId/defaults/idVariable); the clientrenders the real ObjectForm, persists the record (and its children, atomically),
and resumes the run with the saved id bound to
idVariableso a later step canreference it — e.g. a lead-conversion wizard: a full Customer step, then a full
Opportunity-with-line-items step.
ScreenSpecgainskind/objectName/mode/recordId/defaults/idVariable.screenexecutor emits object-form specs and nowinterpolates
title/description/fielddefaultValue/object-formdefaultsagainst live flow variables (the engine does not pre-interpolate node config).
Patch Changes
@objectstack/spec@9.9.0
Minor Changes
d5774b5: fix(spec):
Field.rating/Field.vectorbuilders emit live props instead of dead onesThe
Field.rating(n)andField.vector(n)builders emitted properties thespec-liveness ledger classifies as dead (silent runtime no-ops), so every
field authored through them tripped the
liveness-dead-propertyauthor lint:Field.rating(n)emittedmaxRating, but the rating renderer reads the flatmaxprop (RatingField.tsx:13). The builder now emitsmax.Field.vector(n)emitted a nestedvectorConfigblock, but the rendererreads the flat
dimensionssibling (VectorField.tsx:11) and nothingconsumes
vectorConfig(no vector-index DDL). The builder now emits the flatdimensions.dimensionsis also promoted to a declared, live top-levelFieldSchemaproperty. It was previously only valid nested inside
vectorConfig, so a flatdimensionsauthored by hand was silently stripped during compile (Zoddrops unknown keys) — the renderer then saw no dimensionality. It now survives
compilation and is governed by the liveness gate.
maxRatingandvectorConfigremain accepted by the schema (still classifieddead+authorWarn) for back-compat, so hand-authored usages still surfacethe advisory warning rather than type-erroring.
6bec07e: feat(automation): object-form screen-flow steps
A
screennode that declaresconfig.objectNamenow renders the named object'sFULL create/edit form (including inline master-detail child grids) instead of a
flat field list. The node emits an
object-formScreenSpec(
kind/objectName/mode/recordId/defaults/idVariable); the clientrenders the real ObjectForm, persists the record (and its children, atomically),
and resumes the run with the saved id bound to
idVariableso a later step canreference it — e.g. a lead-conversion wizard: a full Customer step, then a full
Opportunity-with-line-items step.
ScreenSpecgainskind/objectName/mode/recordId/defaults/idVariable.screenexecutor emits object-form specs and nowinterpolates
title/description/fielddefaultValue/object-formdefaultsagainst live flow variables (the engine does not pre-interpolate node config).
Patch Changes
90108e0: feat(cli): liveness author-warning lint — close the spec-liveness loop on the author side.
The liveness ledgers already classify every authorable property live/experimental/dead with evidence, and the CI gate enforces classification completeness — but that knowledge never reached the person (very often an AI) writing the metadata. The new
compilelint (lint-liveness-properties.ts) reads the ledgers and emits an advisory warning when an authored object/field sets a property that is misleading at runtime — e.g.object.enable.feeds(no feed runtime; comments live on sys_comment),object.versioning(no versioning engine),field.columnName(driver ignores it; column == field key),field.maxRating/vectorConfig(renderer reads a different key) — each with a corrective hint toward the supported alternative. Never fails the build (advisory only), consistent with the existing flow anti-pattern lint.Signal-over-noise by design: warnings are opt-in per ledger entry via a new
authorWarn/authorHintannotation (plusexperimentalentries warn by default). Booleans warn only when set truthy, and onlydefault(false)flags are marked, so schema defaults (enable.trash,enable.searchable) never trip it. Coverage grows by annotating more ledger entries, not by changing lint code; today it coversobject(incl.enable.*) andfield.@objectstack/spec: ledger entries gain optionalauthorWarn/authorHint;liveness/is now shipped in the packagefilesso the CLI can read it. Seeded annotations on the misleading object capability flags + aspirational blocks and the misleading dead field props. No schema/runtime change.@objectstack/express@9.9.0
Patch Changes
@objectstack/fastify@9.9.0
Patch Changes
@objectstack/hono@9.9.0
Patch Changes
@objectstack/nestjs@9.9.0
Patch Changes
@objectstack/nextjs@9.9.0
Patch Changes
@objectstack/nuxt@9.9.0
Patch Changes
@objectstack/sveltekit@9.9.0
Patch Changes
@objectstack/account@9.9.0
Patch Changes
@objectstack/setup@9.9.0
Patch Changes
@objectstack/studio@9.9.0
Patch Changes
@objectstack/client@9.9.0
Patch Changes
@objectstack/client-react@9.9.0
Patch Changes
@objectstack/cloud-connection@9.9.0
Patch Changes
@objectstack/connector-mcp@9.9.0
Patch Changes
@objectstack/connector-openapi@9.9.0
Patch Changes
@objectstack/connector-rest@9.9.0
Patch Changes
@objectstack/connector-slack@9.9.0
Patch Changes
@objectstack/core@9.9.0
Patch Changes
@objectstack/formula@9.9.0
Patch Changes
@objectstack/mcp@9.9.0
Patch Changes
@objectstack/metadata@9.9.0
Patch Changes
@objectstack/metadata-core@9.9.0
Patch Changes
@objectstack/metadata-fs@9.9.0
Patch Changes
@objectstack/observability@9.9.0
Patch Changes
@objectstack/platform-objects@9.9.0
Patch Changes
@objectstack/driver-memory@9.9.0
Patch Changes
@objectstack/driver-mongodb@9.9.0
Patch Changes
@objectstack/driver-sql@9.9.0
Patch Changes
796f0d6: fix(driver-sql):
Field.dateis now stored and returned as a tz-naiveYYYY-MM-DDcalendar day (ADR-0053 Phase 1)A
Field.date("close date", "due date", "birthday") is semantically a timezone-naive calendar day, but the SQL driver was treating it as an instant:formatInputwrote the value verbatim (keeping any time component, sodev.dbheldclose_date = "2026-07-15T17:24:56.533Z"), while the filter layer (coerceFilterValue) already normalized the comparand to date-onlyYYYY-MM-DD. That write/filter asymmetry meant a date-equality filter —close_date == '2026-07-15',expires_on: { $in: [...] }, or adaysFromNow(n)-style comparand — compared"2026-07-15T17:24Z"against"2026-07-15"and silently matched nothing.This patch aligns the write/read boundary with the date-only contract the filter already enforced:
formatInput): everyField.datevalue (a JSDate, a full-ISO string, or an already date-only string) collapses toYYYY-MM-DDbefore insert/update. ADatecollapses to its UTC calendar day, matchingcoerceFilterValue.formatOutput):Field.datevalues are returned asYYYY-MM-DD, slicing any stored time component. This transparently repairs legacy rows that were written as a full timestamp, so date-equality works without a data migration. Read normalization now runs on thefindpath for every dialect (previously onlyfindOne), matching the new behaviour.toDateOnlyhelper, so all three agree on what a date is.Field.datetimeis unchanged — it keeps full-instant (UTC millisecond) semantics.Out of scope (ADR-0053 Phase 2): timezone-aware
today()/daysFromNow()/daysAgo(), an org/user reference timezone, anddatetimerender-time TZ. See ADR-0053 and issue Formula guardrail: cel-js arithmetic silently returns null (double × int + bare identifiers) #1928.Updated dependencies [d5774b5]
Updated dependencies [90108e0]
Updated dependencies [6bec07e]
@objectstack/driver-sqlite-wasm@9.9.0
Patch Changes
@objectstack/embedder-openai@9.9.0
Patch Changes
@objectstack/knowledge-memory@9.9.0
Patch Changes
@objectstack/knowledge-ragflow@9.9.0
Patch Changes
@objectstack/plugin-approvals@9.9.0
Patch Changes
@objectstack/plugin-audit@9.9.0
Patch Changes
@objectstack/plugin-auth@9.9.0
Patch Changes
@objectstack/plugin-dev@9.9.0
Patch Changes
@objectstack/plugin-email@9.9.0
Patch Changes
@objectstack/plugin-hono-server@9.9.0
Patch Changes
@objectstack/plugin-msw@9.9.0
Patch Changes
@objectstack/plugin-org-scoping@9.9.0
Patch Changes
@objectstack/plugin-reports@9.9.0
Patch Changes
@objectstack/plugin-security@9.9.0
Patch Changes
@objectstack/plugin-sharing@9.9.0
Patch Changes
@objectstack/plugin-webhooks@9.9.0
Patch Changes
@objectstack/runtime@9.9.0
Patch Changes
@objectstack/service-ai@9.9.0
Patch Changes
@objectstack/service-analytics@9.9.0
Patch Changes
@objectstack/service-cache@9.9.0
Patch Changes
@objectstack/service-cluster@9.9.0
Patch Changes
@objectstack/service-cluster-redis@9.9.0
Patch Changes
@objectstack/service-datasource@9.9.0
Patch Changes
@objectstack/service-i18n@9.9.0
Patch Changes
@objectstack/service-job@9.9.0
Patch Changes
@objectstack/service-knowledge@9.9.0
Patch Changes
@objectstack/service-messaging@9.9.0
Patch Changes
@objectstack/service-package@9.9.0
Patch Changes
@objectstack/service-queue@9.9.0
Patch Changes
@objectstack/service-realtime@9.9.0
Patch Changes
@objectstack/service-settings@9.9.0
Patch Changes
@objectstack/service-storage@9.9.0
Patch Changes
@objectstack/trigger-api@9.9.0
Patch Changes
@objectstack/trigger-record-change@9.9.0
Patch Changes
@objectstack/trigger-schedule@9.9.0
Patch Changes
@objectstack/types@9.9.0
Patch Changes
@objectstack/console@9.9.0
create-objectstack@9.9.0
objectstack-vscode@9.9.0
@objectstack/example-crm@4.0.51
Patch Changes
@objectstack/example-showcase@0.1.21
Patch Changes
@example/app-todo@4.0.51
Patch Changes