Uh oh!
There was an error while loading. Please reload this page.
chore: version packages - #1541
Closed
github-actions[bot] wants to merge 1 commit into
Closed
Conversation
The latest updates on your projects. Learn more about Vercel for GitHub.
|
github-actionsBotforce-pushed
the
changeset-release/main
branch
from
June 2, 2026 10:56
ddd1a96 to
5c85a47Comparegithub-actionsBotforce-pushed
the
changeset-release/main
branch
from
June 2, 2026 12:07
5c85a47 to
8a21eadCompare
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 freeto 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/service-ai@7.7.0
Minor Changes
b391955: feat(ai): blueprint app-building — propose/draft the navigation app, not just the data model
The plan-first blueprint (ADR-0033 §4) now also designs the app (the navigation shell end users open in the App Launcher), so "build me a project-management application" yields an openable app — not just its objects, views, and dashboards.
SolutionBlueprintSchema(@objectstack/spec/ai) gains an optionalapp: { name, label?, icon?, nav? }, where each nav entry targets a created object or dashboard.navmay be omitted to auto-surface every object (then dashboard).apply_blueprintexpands the app into anAppSchemabody (single-levelnavigationof object/dashboard items) and drafts it last — through the same draft-gated, per-type-validatedstageDraftpath as everything else. It never setsisDefault.propose_blueprintnow asks the agent to include the app and reportscounts.app.Still draft-gated: nothing is live until the human publishes. Scope is basic app-building (one app, flat nav); areas/groups/mobile-nav remain author-it-later via
update_metadata.984ddff: feat(service-ai): ADR-0033 Phase A — draft-gate AI metadata authoring
AI metadata mutations no longer publish straight to the live schema. Every write now routes through the ADR-0027 draft workspace via
protocol.saveMetaItem({ mode:'draft' })— nothing an agent authors goes live until a human reviews the diff and publishes. The draft is the approval gate (the never-enforcedrequiresConfirmationflag is retired).Adds a type-agnostic apply surface —
create_metadata/update_metadata/describe_metadata/list_metadata— that works for any metadata type (view, dashboard, flow, …), validated against each type's Zod schema with errors fed back to the agent for self-correction. The existing object/field tools become thin draft-writing wrappers. Tool results return{ status:'drafted', type, name, summary, changedKeys }.f06b64e: feat(ai): ADR-0033 Phase C — plan-first blueprint authoring
For high-level goals ("build me a project-management system") the metadata assistant now designs before it builds. Adds a
SolutionBlueprintSchema(@objectstack/spec/ai) describing proposed objects, fields, relationships, views, dashboards, and seed data with stated assumptions, plus two tools:propose_blueprint(goal)— emits a structured blueprint via structured output. Nothing is persisted; the agent presents it for conversational confirmation and asks at most 1–2 structure-deciding questions.apply_blueprint(blueprint)— only after the human approves, batch-drafts every artifact through the Phase A draft path (protocol.saveMetaItem({mode:'draft'})), validated per-type and partial-tolerant (a bad item is reported, the rest still draft). Seed data is reported as proposed, not auto-applied (no runtimedatasettype).A new
solution_designskill carries the plan-first instructions and is bound tometadata_assistantalongsidemetadata_authoring. The shared draft-write primitive is exported from the metadata tools asstageDraftand reused, keeping one draft-write path.Patch Changes
@objectstack/spec@7.7.0
Minor Changes
b391955: feat(ai): blueprint app-building — propose/draft the navigation app, not just the data model
The plan-first blueprint (ADR-0033 §4) now also designs the app (the navigation shell end users open in the App Launcher), so "build me a project-management application" yields an openable app — not just its objects, views, and dashboards.
SolutionBlueprintSchema(@objectstack/spec/ai) gains an optionalapp: { name, label?, icon?, nav? }, where each nav entry targets a created object or dashboard.navmay be omitted to auto-surface every object (then dashboard).apply_blueprintexpands the app into anAppSchemabody (single-levelnavigationof object/dashboard items) and drafts it last — through the same draft-gated, per-type-validatedstageDraftpath as everything else. It never setsisDefault.propose_blueprintnow asks the agent to include the app and reportscounts.app.Still draft-gated: nothing is live until the human publishes. Scope is basic app-building (one app, flat nav); areas/groups/mobile-nav remain author-it-later via
update_metadata.f06b64e: feat(ai): ADR-0033 Phase C — plan-first blueprint authoring
For high-level goals ("build me a project-management system") the metadata assistant now designs before it builds. Adds a
SolutionBlueprintSchema(@objectstack/spec/ai) describing proposed objects, fields, relationships, views, dashboards, and seed data with stated assumptions, plus two tools:propose_blueprint(goal)— emits a structured blueprint via structured output. Nothing is persisted; the agent presents it for conversational confirmation and asks at most 1–2 structure-deciding questions.apply_blueprint(blueprint)— only after the human approves, batch-drafts every artifact through the Phase A draft path (protocol.saveMetaItem({mode:'draft'})), validated per-type and partial-tolerant (a bad item is reported, the rest still draft). Seed data is reported as proposed, not auto-applied (no runtimedatasettype).A new
solution_designskill carries the plan-first instructions and is bound tometadata_assistantalongsidemetadata_authoring. The shared draft-write primitive is exported from the metadata tools asstageDraftand reused, keeping one draft-write path.023bf93: fix(spec): reject unknown top-level keys on
ObjectSchema.create()(Object-levelworkflows: [...](and any unknown ObjectSchema key) is silently stripped at build — no error/warning (ADR-0032 'no silent failure', metadata layer) #1535)ObjectSchemaBaseis a plainz.object({...})(Zod default.strip()), so anyunknown top-level key passed to
ObjectSchema.create()—workflows, a typo'dvalidation/indexs, etc. — was discarded silently: no error, no warning, and agreen
tsc. Declarative metadata an author believed they shipped (e.g. object-levelworkflows: [...]) vanished from every built artifact, dead from day one. This is themetadata-shape analogue of ADR-0032's "no silent failure" principle.
create()now rejects unknown top-level keys with a precise, fixable build error thatnames the offending key(s), suggests the intended key on a likely typo
(
validation→validations), and — for known-confusable keys likeworkflows—points authors at the supported mechanism (a lifecycle hook
src/objects/<name>.hook.tsor a top-level
record_changeflow; there is no object-levelworkflows[]field). Thefactory signature also constrains excess keys to
never, so the mistake is caught attsctime as well as at build.The non-strict
ObjectSchema.parse()load path (registry/artifact validation) isunchanged.
Also fixes two platform objects (
sys_secret,sys_setting_audit) that carriedsilently-stripped
views/scope/defaultViewNamekeys: their intended list views aremigrated to the supported
listViewsfield (type: 'list'→'grid') so they nowrender instead of being dropped. The
objectstack-dataskill's CRM blueprint no longerteaches the non-existent
workflows[]shape.@objectstack/express@7.7.0
Patch Changes
@objectstack/fastify@7.7.0
Patch Changes
@objectstack/hono@7.7.0
Patch Changes
@objectstack/nestjs@7.7.0
Patch Changes
@objectstack/nextjs@7.7.0
Patch Changes
@objectstack/nuxt@7.7.0
Patch Changes
@objectstack/sveltekit@7.7.0
Patch Changes
@objectstack/cli@7.7.0
Patch Changes
1e0b6d7: fix(cli): honor OS_LOG_LEVEL / --log-level instead of hardcoding the kernel logger to
silent(cli: serve/start hardcodes logger level "silent" — flow & hook execution failures are invisible (defeats ADR-0032 "fail loudly") #1533)os serve/os startbuilt the runtime kernel with a hardcoded{ level: 'silent' }logger, suppressing every pluginlogger.warn/logger.error. A record-change flow whose condition or node faulted (surfaced vialogger.warninplugin-trigger-record-change) produced zero operator-visible output — the flow simply had no effect — undercutting ADR-0032's "fail loudly" promise when run via the CLI.The kernel logger level is now resolved from
--verbose(→debug) →--log-level <level>→$OS_LOG_LEVEL/$LOG_LEVEL→ defaultwarn. Defaulting towarnsurfaces flow/hook execution-failure warnings and automation-engine errors out of the box, while the existing boot-quiet window still suppresses info-level startup chatter. Pass--log-level silent(orOS_LOG_LEVEL=silent) to restore the previous fully-quiet behavior.startanddevgain a matching--log-levelflag and forward it (plus the existing--verbose) to the spawnedserve.Updated dependencies [b391955]
Updated dependencies [984ddff]
Updated dependencies [f06b64e]
Updated dependencies [825ab06]
Updated dependencies [023bf93]
@objectstack/client@7.7.0
Patch Changes
@objectstack/client-react@7.7.0
Patch Changes
@objectstack/connector-mcp@7.7.0
Patch Changes
@objectstack/connector-openapi@7.7.0
Patch Changes
@objectstack/connector-rest@7.7.0
Patch Changes
@objectstack/connector-slack@7.7.0
Patch Changes
@objectstack/core@7.7.0
Patch Changes
@objectstack/formula@7.7.0
Patch Changes
825ab06: fix(formula): hydrate string-serialized numeric fields in CEL comparisons (automation: flow conditions on numeric string-serialized fields (rating/currency/percent) fault under strict CEL and silently dead-end the flow (sibling of #1530) #1534)
Numeric fields that serialize as strings —
Field.rating(allowHalf)→"5.0",Field.currency(scale)→"250000.00",Field.percent— made comparisons likerecord.rating >= 4fault under strict CEL withno such overload: dyn >= int. In flow decision/edge conditions this silently dead-ended the run (no edge matched), and in objectqlapplyFormulaPlanit swallowed tonull.The CEL engine now retries an evaluation once with purely-numeric strings hydrated to numbers, but only after a
no such overloadfault — so a comparison that already type-checks is never re-interpreted (a zip like"02134"stays a string inrecord.zip == "02134"). Because both the automation condition path (service-automationevaluateCondition) and the objectql formula path route throughExpressionEngine.evaluate, both are fixed consistently. A genuinely non-numeric operand (e.g.record.rating >= 4whereratingis"high") still faults loudly rather than being silently rescued.Updated dependencies [b391955]
Updated dependencies [f06b64e]
Updated dependencies [023bf93]
@objectstack/metadata@7.7.0
Patch Changes
@objectstack/metadata-fs@7.7.0
Patch Changes
@objectstack/objectql@7.7.0
Patch Changes
@objectstack/observability@7.7.0
Patch Changes
@objectstack/platform-objects@7.7.0
Patch Changes
023bf93: fix(spec): reject unknown top-level keys on
ObjectSchema.create()(Object-levelworkflows: [...](and any unknown ObjectSchema key) is silently stripped at build — no error/warning (ADR-0032 'no silent failure', metadata layer) #1535)ObjectSchemaBaseis a plainz.object({...})(Zod default.strip()), so anyunknown top-level key passed to
ObjectSchema.create()—workflows, a typo'dvalidation/indexs, etc. — was discarded silently: no error, no warning, and agreen
tsc. Declarative metadata an author believed they shipped (e.g. object-levelworkflows: [...]) vanished from every built artifact, dead from day one. This is themetadata-shape analogue of ADR-0032's "no silent failure" principle.
create()now rejects unknown top-level keys with a precise, fixable build error thatnames the offending key(s), suggests the intended key on a likely typo
(
validation→validations), and — for known-confusable keys likeworkflows—points authors at the supported mechanism (a lifecycle hook
src/objects/<name>.hook.tsor a top-level
record_changeflow; there is no object-levelworkflows[]field). Thefactory signature also constrains excess keys to
never, so the mistake is caught attsctime as well as at build.The non-strict
ObjectSchema.parse()load path (registry/artifact validation) isunchanged.
Also fixes two platform objects (
sys_secret,sys_setting_audit) that carriedsilently-stripped
views/scope/defaultViewNamekeys: their intended list views aremigrated to the supported
listViewsfield (type: 'list'→'grid') so they nowrender instead of being dropped. The
objectstack-dataskill's CRM blueprint no longerteaches the non-existent
workflows[]shape.Updated dependencies [b391955]
Updated dependencies [f06b64e]
Updated dependencies [023bf93]
@objectstack/driver-memory@7.7.0
Patch Changes
@objectstack/driver-mongodb@7.7.0
Patch Changes
@objectstack/driver-sql@7.7.0
Patch Changes
@objectstack/driver-sqlite-wasm@7.7.0
Patch Changes
@objectstack/embedder-openai@7.7.0
Patch Changes
@objectstack/knowledge-memory@7.7.0
Patch Changes
@objectstack/knowledge-ragflow@7.7.0
Patch Changes
@objectstack/plugin-approvals@7.7.0
Patch Changes
@objectstack/plugin-audit@7.7.0
Patch Changes
@objectstack/plugin-auth@7.7.0
Patch Changes
@objectstack/plugin-dev@7.7.0
Patch Changes
@objectstack/plugin-email@7.7.0
Patch Changes
@objectstack/plugin-hono-server@7.7.0
Patch Changes
@objectstack/plugin-mcp-server@7.7.0
Patch Changes
@objectstack/plugin-msw@7.7.0
Patch Changes
@objectstack/plugin-org-scoping@7.7.0
Patch Changes
@objectstack/plugin-reports@7.7.0
Patch Changes
@objectstack/plugin-security@7.7.0
Patch Changes
@objectstack/plugin-sharing@7.7.0
Patch Changes
@objectstack/plugin-trigger-record-change@7.7.0
Patch Changes
@objectstack/plugin-trigger-schedule@7.7.0
Patch Changes
@objectstack/plugin-webhooks@7.7.0
Patch Changes
@objectstack/rest@7.7.0
Patch Changes
@objectstack/runtime@7.7.0
Patch Changes
@objectstack/service-analytics@7.7.0
Patch Changes
@objectstack/service-automation@7.7.0
Patch Changes
@objectstack/service-cache@7.7.0
Patch Changes
@objectstack/service-cluster@7.7.0
Patch Changes
@objectstack/service-cluster-redis@7.7.0
Patch Changes
@objectstack/service-datasource@7.7.0
Patch Changes
@objectstack/service-feed@7.7.0
Patch Changes
@objectstack/service-i18n@7.7.0
Patch Changes
@objectstack/service-job@7.7.0
Patch Changes
@objectstack/service-knowledge@7.7.0
Patch Changes
@objectstack/service-messaging@7.7.0
Patch Changes
@objectstack/service-package@7.7.0
Patch Changes
@objectstack/service-queue@7.7.0
Patch Changes
@objectstack/service-realtime@7.7.0
Patch Changes
@objectstack/service-settings@7.7.0
Patch Changes
@objectstack/service-storage@7.7.0
Patch Changes
@objectstack/types@7.7.0
Patch Changes
@objectstack/account@7.7.0
@objectstack/console@7.7.0
create-objectstack@7.7.0
@objectstack/metadata-core@7.7.0
objectstack-vscode@7.7.0
@objectstack/example-crm@4.0.35
Patch Changes
@objectstack/example-showcase@0.1.5
Patch Changes
@example/app-todo@4.0.35
Patch Changes