Merge remote-tracking branch 'origin/main' into claude/objectui-spec-symbol-ci-rule-4r3xlc-batch4

Author: claude

.changeset/cross-repo-issue-closer.md

@@ -0,0 +1,31 @@
+---
+---
+
+ci: close issues that a merged PR fixes in another repository
+
+Release-nothing: adds `.github/workflows/cross-repo-issue-closer.yml` and no
+package code.
+
+Defects are routinely found in objectstack, where verification runs, and fixed
+here. But GitHub's closing keywords only act within a repository, so a PR here
+saying `Fixes objectstack-ai/objectstack#4475` merges and leaves that framework
+issue open — with no reference to the PR on the issue's own page either. v17
+verification hit this twice in one day: #3150 fixed objectstack#4475 and #3163
+fixed objectstack#4478, and both were closed by hand.
+
+The job has two modes and both are visible. With a cross-repo token it closes
+the foreign issue and links the PR. Without one it comments on the merged PR
+naming what still needs closing by hand — this repository's secrets are
+`GITHUB_TOKEN` (scoped to the repository running the workflow, which is the
+whole problem), `NPM_TOKEN` and `CODECOV_TOKEN`, so until an admin provisions
+`CROSS_REPO_ISSUE_TOKEN` the job cannot perform the close at all.
+
+That second mode is deliberate, not a fallback. A workflow that quietly does
+nothing because a secret was never provisioned is the "declared but never
+enforced" shape both repositories keep having to fix. A missing credential has
+to announce itself.
+
+Matched references are restricted to the qualified `owner/repo#N` form; the
+bare `#N` form already works natively and is left alone. Same-repo qualified
+references are filtered out, already-closed targets are skipped, and one
+unreachable target cannot swallow the rest or read as success.

.changeset/decision-output-def-collapses-to-spec.md

@@ -0,0 +1,38 @@
+---
+"@object-ui/app-shell": patch
+---
+
+Collapse app-shell's `DecisionOutputDef` to a plain re-export of the spec's
+(objectstack#4562).
+
+The local type was `interface DecisionOutputDef extends SpecDecisionOutputDef
+{ required?: boolean }` — a structural derivation carrying ONE documented
+divergence, because the server enforced `required` (`decide()` rejects a blank
+required output before any write) while `@objectstack/spec` did not model it.
+The spec adopted `required` in cd6b9f202 and pinned it at the schema level in
+objectstack#4561, and this repo now resolves a spec that has it
+(`@objectstack/spec@17.0.0-rc.1`, #3178). The addition is therefore redundant
+and the type becomes `export type DecisionOutputDef = SpecDecisionOutputDef`.
+
+No behavior change and no API change: the symbol is internal to this package
+(it is not re-exported from `src/index.ts`), the resolved shape is identical
+key-for-key, and `decisionOutputParams()` still reads `d.required` — now off
+the spec's own field.
+
+The module TSDoc still asserted "the spec does not model it yet", which was
+stale and actively misleading — an agent reading it would take the divergence
+as ground truth and build on it, which is the objectstack#4115 failure class
+this file's own tripwires exist to prevent. It now states the current truth.
+
+The parity pin in `__tests__/spec-symbol-parity.test.ts` is inverted
+accordingly: `Exclude<keyof DecisionOutputDef, keyof SpecDecisionOutputDef>`
+is asserted `never` rather than `'required'`, plus an exact-identity
+assertion, so a future local addition to this symbol cannot slip in
+undocumented. The `type`-is-the-spec's-closed-enum pin is unchanged — that
+narrowing is still what stops a typo'd picker kind from silently degrading to
+a raw record-id text box (objectui#2955).
+
+Note that this pin, like every other type-level assertion in that file, is not
+yet compiled by any gate — package tsconfigs exclude `**/*.test.ts`, so
+nothing type-checks it. It was verified by compiling the file explicitly. See
+objectui#3181.

.changeset/fix-cross-repo-closer-require.md

@@ -0,0 +1,18 @@
+---
+---
+
+fix(ci): hand the cross-repo token to github-script instead of requiring @actions/github
+
+Release-nothing: touches `.github/workflows/cross-repo-issue-closer.yml` only.
+
+`require('@actions/github')` is not resolvable from a github-script `script:`
+block — the action bundles its dependencies, so the call fails at runtime with
+`MODULE_NOT_FOUND`. The token is now handed to the action itself
+(`github-token:`), which makes the injected `github` client the cross-repo one,
+with `secrets.GITHUB_TOKEN` as the fallback so the report path can still
+comment on the pull request when no cross-repo credential is configured.
+
+Found on this workflow's first run that got past parsing. The run also
+confirmed the credential logging works — `CROSS_REPO_ISSUE_TOKEN: configured`
+followed by `Cross-repo targets: objectstack-ai/objectstack#4475` — so the
+job now fails at the last step rather than the first.

.changeset/form-designer-speaks-the-project-language.md

@@ -0,0 +1,24 @@
+---
+"@object-ui/app-shell": minor
+---
+
+fix(studio): the form-layout canvas resolves the object's field and section translations (#3134)
+
+`ObjectFormDesigner` bills itself as a preview of the end-user form, but it read
+labels straight off the object draft — `entry.def.label` for fields, `group.label`
+for section headers. Every other surface for the same object (`ObjectForm`,
+`RecordDetailView`, the data grid) resolves those through the project's object
+translations first, so a fully translated object rendered `Opportunity Name` /
+`Basic Information` on the layout canvas while the very same fields read
+`商机名称` / `基本信息` one click away.
+
+The designer now goes through `useSafeFieldLabel()` — `fieldLabel()` for field
+cards (including the drag overlay) and `sectionLabel()` for section headers —
+which is the same resolver the runtime form uses, with the authored metadata
+label as fallback when no translation exists. The lookup root is the object's
+API name; `StudioDesignSurface` now passes it explicitly (`objectName`) so a
+draft body that has not been re-named still resolves, falling back to
+`draft.name`.
+
+Observable rendering change (translated labels now appear where English source
+labels did), hence `minor`.

.changeset/nav-action-dispatch.md

@@ -0,0 +1,39 @@
+---
+"@object-ui/layout": minor
+"@object-ui/app-shell": minor
+---
+
+Navigation `action` items actually run now (framework#4509).
+
+A `type: 'action'` nav item rendered, gated like any other item, and did
+**nothing** when clicked. `NavigationRenderer` dispatches such a click to an
+`onAction` prop it expects the host shell to supply — it deliberately never
+reads `item.actionDef` itself — and no shipped sidebar supplied that prop. So
+`actionDef.actionName` reached no dispatcher: an author could put an action in
+the menu, watch it render with its icon and label, and never find out that
+clicking it was a no-op. The framework's liveness ledger recorded this as the
+single gap in the AppSchema navigation surface.
+
+**New `useNavActionDispatch`** (`@object-ui/app-shell`) resolves the nav item's
+`actionName` against `action` metadata at click time — the same source
+`DeclaredActionsBar` reads for a record toolbar — and dispatches the resolved
+definition through `useAction()`. `UnifiedSidebar` now passes it. No new
+provider is involved: the sidebar already renders inside `ConsoleShell`'s
+`GlobalActionRuntimeProvider`, so nav actions get the fully-wired console runner
+including the confirm, param-collection, result and navigate dialogs. A declared
+`params` array becomes the runner's param-dialog input, and the nav item's own
+`actionDef.params` is passed as the value bag, so a menu entry can pre-fill the
+action it launches.
+
+Nav actions are inherently **global**: `ActionNavItemSchema` is strict with
+exactly `{ actionName, params? }` and carries no `objectName`, so resolution is
+by name alone and no record context rides along.
+
+**Behaviour change:** a shell that passes no `onAction` no longer renders
+`action` items at all, instead of rendering them dead. This mirrors the existing
+capability guards — an item the host cannot serve is hidden — and it makes the
+omission diagnosable: a missing prop now shows up as "my action item is gone",
+which leads to the prop, rather than "clicking does nothing", which for three
+releases led nowhere. Every failure at dispatch time (an unnamed item, an
+unresolvable action, a throwing action) warns and toasts instead of returning
+silently.

.changeset/spec-rc1-wait-timeout-fields-retired.md

@@ -0,0 +1,61 @@
+---
+"@object-ui/app-shell": minor
+"@object-ui/types": minor
+"@object-ui/plugin-dashboard": patch
+"@object-ui/plugin-report": patch
+---
+
+Upgrade to `@objectstack/spec@17.0.0-rc.1`, stop offering the retired `wait` timeout fields (#3101), and route the newly-adopted `combo` chart type.
+
+**Breaking for authoring, and the reason to do it now**: the `wait` panel no longer offers
+`waitEventConfig.timeoutMs` or `.onTimeout`. Both are `retiredKey()` tombstones as of spec
+17.0.0-rc.1 (framework#4158), which means a value written there is **rejected at load** —
+so until this lands, Studio can produce flow metadata the author's own runtime refuses.
+That hazard opened the moment rc.1 published, independent of when this repo bumps.
+
+`wait` never had a timeout: `onTimeout` had zero readers, so neither `'fail'` nor
+`'continue'` ever happened, and `timeoutMs`'s only reader used it as the timer **duration**
+when `timerDuration` was absent. Use **Duration** — it accepts a bare number as
+milliseconds, making the old `timeoutMs: 60000` and `timerDuration: '60000'` the same wait.
+Stored flows are converted by framework's D2 conversion; the designer simply stops offering
+the entry. The two `zh` label overrides go with the fields.
+
+#3101 asked for this to ride along with the bump rather than land alone, and that is
+load-bearing: the sibling-block assertion is **bidirectional**, so deleting the fields
+against a spec that still declares them fails in the other direction.
+
+**`combo` is now a spec chart type** — the sole addition to `ChartTypeSchema` in rc.1 (19
+members → 20). It had been a renderer-local family the chart renderer derived from the
+series, so nothing classified it on the two surfaces that route a *spec* chart type: a
+spec-valid `combo` fell through to the red "Unknown component type" panel on a dashboard
+and to the out-of-spec notice on a report. Both now route it
+(`widgetDispatch.SERIES_CHART_TYPES`, `planReportChart`). The renderer-local derivation
+stays — it is what makes an authored `type: 'combo'` render rather than merely validate.
+
+**Retired spec exports this repo bound to**, all removed upstream in spec 17.0.0:
+
+- `JoinStrategy` / `WindowFunction` (framework#4286 tombstoned `query.joins` and
+  `query.windowFunctions`: no engine or driver ever read either on the query path). They
+  were derived off the spec enums under objectstack#4115's "come off the spec enum, not a
+  restatement" rule; with no enum left, `data-protocol.ts` now restates the members locally
+  — verbatim from the last spec that published them — as the objectui query-AST vocabulary
+  they have become. The AST itself is unchanged.
+- `PerformanceConfig`, retired with `dashboard.performance` (framework#3896). Nothing bound
+  to it — `@object-ui/react`'s `usePerformance` declares its own interface and is untouched.
+  The dashboard form is derived from the spec's own `dashboardForm`, so the field
+  disappears from the inspector for free; its test now pins the absence.
+
+**Three inverted pins fired, and are recorded rather than resolved.** objectstack#4171's
+tripwires asserted that `NavigationItem`, `FormField` and `ConditionalValidation`'s branches
+still erased to `any`/`unknown` upstream — the premise that justified objectui keeping local
+declarations. rc.1 types them properly, so the assertions are inverted to state the new
+fact. The burn-down each one asks for — deriving those types from the spec — touches
+widely-used public types and is deliberately **not** bundled into a version bump; it is
+tracked in #3177. `JoinNode`'s pin is gone outright: the symbol no longer exists.
+
+**What the bump arms.** The reconciliation ledger's `subflow` and `decision` panels
+feature-detect their spec exports and had never actually run — rc.0 predates the exports
+(framework#4278). They now execute and pass. The `script` panel's full bidirectional check
+stays deliberately skipped: rc.1 predates framework#4343, so the retired dispatch branches
+are still contract keys there, and only the "offers nothing the executor ignores" direction
+is meaningful. It arms itself on the next rc.

.changeset/timeline-honours-its-configured-date-field.md

@@ -0,0 +1,30 @@
+---
+"@object-ui/plugin-timeline": minor
+"@object-ui/plugin-list": minor
+---
+
+fix(timeline,list): the timeline honours `timeline.dateField`, not just `timeline.startDateField` (#3129)
+
+`dateField` is the pre-#2231 alias for `startDateField`. `@object-ui/types`
+declares it on the nested config (`ListViewTimelineConfig`), and both
+`ObjectView` read-sites (app-shell and plugin-view) resolve it — but the two
+read-sites that actually drive the axis did not:
+
+- `ObjectTimeline` consulted the alias only on the FLAT prop (`schema.dateField`),
+  never on the nested `schema.timeline`.
+- `ListView` resolved it out of `options.timeline` but not out of the
+  spec-canonical `schema.timeline` — including in the capability gate, so such a
+  view could fail to offer the Timeline option at all.
+
+So a view authored as `timeline: { dateField: 'start_date' }` — the spec nesting
+with the legacy key — fell through to the caller's default (`created_at` /
+`due_date`). That field is normally absent from the `$select` projection, so
+every record came back without it and the timeline rendered all of them under
+**No date** — while the configured date was sitting in the row untouched. That
+also explains why widening the view's projection changed nothing: the projection
+already carried the right field; the renderer was reading a different one.
+
+Both read-sites now resolve the alias in the same precedence position they
+already use for `options.timeline.dateField`. The spec key still wins wherever
+both appear. Observable rendering change (records move out of "No date" into
+real date buckets), hence `minor`.