Merge branch 'main' into claude/issue-10899-hosted-console-ux-defects

Author: hotlong

.changeset/10321-named-view-kanban-groupby-refused.md

@@ -21,6 +21,18 @@ bag. The issue is `custom` at `listViews.KEY.kanban.groupBy` or
 `groupBy`. Did you mean `groupBy` → `groupByField`?", followed by the same
 explanation. Write `groupByField` (or the deprecated `groupField`).
 
+⚠️ **Dated note, 2026-09-28 — `listViews` has since been mirrored, and the
+`options.kanban` bag is refused whole — objectui#7928.** Later in this same release
+`ObjectViewSchema.listViews` became the protocol's strict `ObjectListViewSchema` record,
+by reference, so "`ObjectViewSchema.listViews` is unmirrored" above no longer holds. The
+protocol now refuses `listViews.KEY.kanban.groupBy` itself (`unrecognized_keys` at
+`listViews.KEY.kanban`), and this check still adds its `custom` issue at
+`listViews.KEY.kanban.groupBy`, with the same message. It no longer judges the legacy
+bag: the record refuses a named view's `options` whole (`unrecognized_keys` at
+`listViews.KEY`, naming `options`), so nothing reports
+`listViews.KEY.options.kanban.groupBy`. `.changeset/7928-listviews-by-reference-fold.md`
+(PR objectui#10821) states what ships; the text above is kept as the reading of this change.
+
 The protocol agrees on this route too. Measured on `@objectstack/spec` 17.4.0
 when this change was made, `ViewSchema` refuses `listViews.KEY.kanban.groupBy`
 as an unrecognized key exactly as `ListViewSchema` refuses `kanban.groupBy`,
@@ -43,3 +55,16 @@ an undeclared sibling in the kanban block nor the legacy `options` bag itself;
 the value type `listViews` should enforce is objectui#7928's. `groupBy` is not
 honoured as an alias (the ruling rules that out), and `groupBy` on the generated
 `object-kanban` node, the lane key `ObjectKanban` reads, is untouched.
+
+⚠️ **Dated note, 2026-09-28 — what a written key now reports, and what the record now
+refuses — objectui#7928.** Later in this same release the named-view record became the
+protocol's own, by reference. A `groupBy` in a named view's `kanban` block now reports
+two issues, the protocol's `unrecognized_keys` and this entry's pointer; one in the
+`options.kanban` bag reports only the refusal of `options`, which names neither `groupBy`
+nor `groupByField`. So "one issue per written key, naming the key and the replacement"
+no longer holds. `ObjectViewSchema` now declares the value type the paragraph above
+defers to objectui#7928: `listViews` is in its shape, a named view needs `columns`, and
+the record refuses an undeclared sibling in the kanban block and the `options` bag. This
+entry's check now adds its message to a document the record already refuses.
+`.changeset/7928-listviews-by-reference-fold.md` (PR objectui#10821) states what ships;
+the text above is kept as the reading of this change.

.changeset/10584-object-chart-series-describe.md

@@ -15,5 +15,16 @@ The TypeScript docblock on the same member now says the omission is deliberate
 rather than a lag: taking `type` up would widen a published accept set, and
 that waits for a named producer that writes it on an `object-chart` node.
 
+⚠️ **Dated note, 2026-09-28 — `series` has since become two arms — objectui#10770.** Later
+in this same release each `ObjectChartSchema.series` entry became ONE of two arms, on
+both faces: the spec's `ChartSeriesSchema` (`{ name }`, by reference, the AUTHOR arm) or
+the internal `{ dataKey }` arm. The `.describe()` and the docblock now describe both. So
+"the copy is that `{ dataKey }` arm minus its per-series `type`" holds for the internal
+arm only, and `chartType` is the per-series family override on that arm only: on a
+`{ name }` entry the override is the spec's `type`, which an `object-chart` node now
+accepts. The deliberate omission of `type` stands on the `{ dataKey }` arm, where the
+zod mirror still strips it. `.changeset/10770-object-chart-react-tier-node.md` (PR
+objectui#10802) states what ships; the text above is kept as the reading of this change.
+
 Wording only. The accepted shape does not move on either face: the element
 type, its members and the mirror's parse result are what they were.

.changeset/10893-signup-carries-verification-callback.md

@@ -0,0 +1,32 @@
+---
+'@object-ui/auth': minor
+'@object-ui/console': patch
+---
+
+fix(auth, console): a registration started from an invitation link comes back to the invitation after email verification
+
+better-auth builds the verification mail's link server-side from the
+`/sign-up/email` request's `callbackURL`, defaulting it to `/`. The console kept
+`?redirect=/accept-invitation/ID` from the login page through `/register` to the
+"check your inbox" screen, but `createAuthClient().signUp` never sent a
+`callbackURL`, so the mail read `callbackURL=/` and the invitee verified onto the
+workspace picker ("Create workspace") instead of the invitation.
+
+`@object-ui/auth` (additive):
+
+- `SignUpData.callbackURL` is forwarded verbatim to `/sign-up/email`. Absent, the
+  key stays off the wire and the server default is untouched.
+- `useAuth().signUp(name, email, password, callbackURL?)` takes it as an optional
+  fourth argument.
+- `RegisterForm` gains a `verificationCallbackURL` prop, forwarded to `signUp`.
+
+`@object-ui/console`:
+
+- `RegisterPage` passes a safe `?redirect=` as the verification callback, and the
+  verify-email prompt's "Resend" sends the same value. Before, Resend sent the
+  bare router path, which the server redirects to at the ORIGIN root, outside
+  the `/_console` mount.
+- Both resolve the route through the new `withConsoleBaseRootRelative`. The server
+  never sees `<base href>`, and better-auth refuses a document-relative `./…`
+  callback — what `withConsoleBase` answers in the embedded build — with
+  `403 INVALID_CALLBACK_URL`, failing the whole sign-up.

.changeset/10916-joined-report-block-pin-two-specs.md

@@ -0,0 +1,9 @@
+---
+---
+
+Rewrite the `JoinedReportBlock` pin in `report-chart-query-spec-parity.test.ts`
+(objectui#10916) so it compiles against both the installed `@objectstack/spec`
+17.4.0, which still erases the block type to `unknown`, and spec `main`, which
+objectstack#20369 typed. A test-time tripwire now fails at the first spec bump
+past 17.4.0, which is when the burn-down it records becomes possible. Test and
+ledger text only; no package is released by this change.

.changeset/7924-named-list-view-retire.md

@@ -7,6 +7,16 @@ sixteen members on its TypeScript authoring face (objectui#7924). Each is now a
 `?: never` tombstone: a TypeScript author who writes one gets a compile error at that
 key, and the member's docblock names the key to write instead.
 
+⚠️ **Dated note, 2026-09-28 — `NamedListView` no longer types a named view —
+objectui#7928.** Later in this same release `ObjectViewSchema.listViews` became the
+protocol's own record by reference: on both faces its value is `@objectstack/spec`'s
+strict `ObjectListViewSchema`, and a `NamedListView` is not assignable to it. So "one
+entry of `ObjectViewSchema.listViews`" above no longer holds. `NamedListView` stays
+exported with the tombstones this entry describes; a retired spelling written in a
+named view is refused there by the protocol's record as an unrecognized key, not by a
+tombstone here and its pointer. `.changeset/7928-listviews-by-reference-fold.md` (PR
+objectui#10821) states what ships; the text above is kept as the reading of this change.
+
 **The eight legacy `show*` spellings** (bucket ② of the director-seat ruling on
 objectui#7924, letter **A**). None is a protocol key on a view; the protocol's
 `userActions` and `appearance` blocks are the canonical home, and `NamedListView`
@@ -43,6 +53,14 @@ row-colour configuration `rowColor: { field }`, and `addRecordViaForm` at the
 `densityMode` is folded onto `rowHeight` by `normalizeListViewSchema`. They stay
 declared as they were.
 
+⚠️ **Dated note, 2026-09-28 — `densityMode` has since been retired too — objectui#7924.**
+Later in this same release ruling A′ made `NamedListView.densityMode` a `?: never`
+tombstone as well, its docblock pointing at top-level `rowHeight`. So "Two bucket-③
+members are NOT retired" and "They stay declared as they were" now hold for
+`allowExport` only. `normalizeListViewSchema` still folds a stored `densityMode` onto
+`rowHeight`. `.changeset/7924-density-mode-through-fold.md` (PR objectui#10793) states
+what ships; the text above is kept as the reading of this change.
+
 **Only the authoring face changes.** Stored view documents that still carry a legacy
 spelling keep loading: `normalizeListViewSchema` (`@object-ui/core`) still folds the eight
 `show*` flags onto `userActions` / `appearance` at runtime, and hosts that read a stored

.changeset/8355-retire-calendar-date-aliases.md

@@ -84,6 +84,20 @@ to `SchemaRenderer` never parses the mirror at all — `SchemaRenderer` runs the
 structural core validator, which is dev-only and names no key — so the compiler
 is that population's channel, not this one.
 
+⚠️ **Dated note, 2026-09-28 — a named view's `options.calendar` nesting is no longer
+judged inside — objectui#7928.** Later in this same release `ObjectViewSchema.listViews`
+became the protocol's strict `ObjectListViewSchema` record, by reference, and that
+record refuses a named view's `options` bag whole (`unrecognized_keys` at
+`listViews.KEY`, naming `options`). So an alias written under
+`listViews.KEY.options.calendar` no longer draws an issue naming the key or the remedy.
+The named view's `calendar` block still does: the protocol refuses the alias there as an
+unrecognized key, and this entry's check adds the pointer at the key beside it. A stored
+body that `@object-ui/app-shell`'s `ViewPreview` relays has its `options.calendar` folded
+onto the `calendar` block first (`foldStoredListOptions`). The list view's two nestings
+and both `object-calendar` surfaces are unchanged; `calendar-date-alias-refusal-8355.test.ts`
+in `@object-ui/types` re-derives each surface. `.changeset/7928-listviews-by-reference-fold.md`
+(PR objectui#10821) states what ships; the text above is kept as the reading of this change.
+
 ⚠️ **Why this is `minor` and not `major`.** This repository forbids `major` in a
 changeset: the fixed release group's major tracks `@objectstack`'s, so any
 `major` here would push all of it off that cadence
@@ -136,6 +150,19 @@ undeclared key nor the legacy `options` bag. It judges exactly the two spellings
 this entry retires, at the two nestings the producer merges — with pins on each
 of those non-effects.
 
+⚠️ **Dated note, 2026-09-28 — `listViews` has since been mirrored — objectui#7928.** Later
+in this same release the maintainer's ruling A chose the value type this paragraph waits
+on: `ObjectViewSchema.listViews` is now `@objectstack/spec`'s own
+`ViewSchema.shape.listViews`, a record of the strict `ObjectListViewSchema`, by reference
+on both faces. It is in the object's `shape`, a named view needs `columns`, and the
+record refuses an undeclared key and the legacy `options` bag whole. The named-view check
+described here and in the `@object-ui/types` bullet above now reads the protocol's own
+refusal at `listViews.KEY.calendar` and adds the pointer at the key; it no longer walks
+the `options.calendar` nesting, so "a named view's two nestings" and "at the two nestings
+the producer merges" now hold for the `calendar` block only.
+`.changeset/7928-listviews-by-reference-fold.md` (PR objectui#10821) states what ships;
+the text above is kept as the reading of this change.
+
 ⛔ **Not a producer-side fold.** Normalising `dateField` to `startDateField` in
 `ListView` (option A) was put to the director seat and refused as the end state:
 it keeps a second spelling alive at the producer, which is the lenient alias
@@ -184,3 +211,12 @@ structural guard that `listViews` stays out of the object's `shape`),
 reading the node their producer really emits through a spy registration, which is
 the only census that can see a key arriving through a spread — and the inverted
 ledger rows in `calendarUnionReads-8651.test.tsx` (`@object-ui/plugin-calendar`).
+
+⚠️ **Dated note, 2026-09-28 — a named view now refuses `timeline.dateField`, and the
+shape guard is inverted — objectui#7928.** Later in this same release the protocol's
+strict named-view record refuses `timeline.dateField` on a named view as an unrecognized
+key; the `list-view` route still accepts it, and that route is the one the timeline pin
+reads. The structural guard in `calendar-date-alias-refusal-8355.test.ts` now asserts
+the opposite of "`listViews` stays out of the object's shape": `listViews` is a member
+of `ObjectViewSchema.shape`. `.changeset/7928-listviews-by-reference-fold.md` (PR
+objectui#10821) states what ships; the text above is kept as the reading of this change.

.changeset/8365-stray-kanban-groupby-refused.md

@@ -40,6 +40,19 @@ fallback and was **not** taken):
    this arm; objectui#10321 gives that route its own door, which refuses the key
    in either nesting with the same message.
 
+⚠️ **Dated note, 2026-09-28 — a named view's `options.kanban` bag is refused whole —
+objectui#7928.** Later in this same release a named view became the protocol's strict
+`ObjectListViewSchema` record, by reference, which refuses its `options` bag by name
+(`unrecognized_keys` at `listViews.KEY`, naming `options`). So the objectui#10321 door no
+longer refuses the key "in either nesting with the same message": it still adds that
+message at `listViews.KEY.kanban.groupBy`, beside the protocol's own refusal of the key,
+and nothing reports `listViews.KEY.options.kanban.groupBy`. A stored body that
+`@object-ui/app-shell`'s `ViewPreview` relays has its `options.kanban` folded onto the
+`kanban` block first (`foldStoredListOptions`). The `list-view` route described above is
+unchanged, its `options.kanban` check included.
+`.changeset/7928-listviews-by-reference-fold.md` (PR objectui#10821) states what ships;
+the text above is kept as the reading of this change.
+
 **Breaking, in the sense worth stating explicitly** (shipped `minor`: this repo
 never declares `major`, and `.changeset/config.json` puts every package in one
 `fixed` group, so levels cannot be split). Two behaviours change for **stored

.changeset/8725-formsection-group-resolves.md

@@ -0,0 +1,20 @@
+---
+'@object-ui/app-shell': minor
+---
+
+The metadata-admin `SchemaForm` no longer crashes on a form section that references a field group, and the form-section authoring type accepts that shape (objectui#8725).
+
+**Clause-②: yes** — two exported types change shape. `FormSectionSpec.fields` becomes optional, which widens what an author may write to match `@objectstack/spec`. `RichMetadataTypeEntry.form` narrows from `Record<string, unknown>` to `FormViewSpec`.
+
+**BREAKING (types).** A consumer that reads `section.fields` unguarded, or indexes `FormSectionSpec['fields'][number]`, no longer compiles (`TS18048` / `TS2537`), because a `{ group }` section carries no `fields`. Read the element type through `NonNullable`. Do not default the list with `?? []`: a `{ group }` section then renders as a silently empty one. A consumer that treated `RichMetadataTypeEntry.form` as an open record now gets the `FormViewSpec` keys only. Outside `SchemaForm`, whose three reads are what this change fixes, no published source in this repository had to change. The other readers that changed were tests: two type-level pins, one in this package and one in `apps/console` (`FormPage.fieldSpec.test.ts`), and four `mergeServerFields` assertions.
+
+**What was wrong.** `@objectstack/spec` lets a form section declare its members one of two ways: enumerate `fields`, or point `group` at a declared field group. The `/meta/types` registry hands its form document to `SchemaForm` without validation, and a `{ group }` section reached the renderer's first `fields` read. That read threw `TypeError: s.fields is not iterable` out of the component body and blanked the whole form, well-formed sections included, on both the simple and the tabbed layout. The required `fields` on `FormSectionSpec` only stopped a TypeScript author from writing the shape; the server channel carried it anyway, through an `as any` cast.
+
+**What changed, in observable terms.**
+
+- Every read of a section's `fields` in `SchemaForm` now sees a resolved section. A `{ group }` section goes through `@object-ui/plugin-form`'s `resolveSectionGroupReferences`, the resolver `ObjectForm` and the console `FormPage` already use, so `SchemaForm` gives their answer.
+- No `SchemaForm` host carries an object definition, and `/meta/types` declares no field groups for a metadata type. So a `{ group }` section in a metadata-type editor names no declared field group. For that case the resolver renders the section empty and reports the dangling key once on `console.error`, naming the group and the form's `schemaId`. The other sections render normally.
+- A section that declares neither `fields` nor `group` is still refused out loud. The render throws a `TypeError` that names the section; it does not draw an empty section.
+- `RichMetadataTypeEntry.form` is typed `FormViewSpec`, and the `as any` casts where `ResourceEditPage` and `EmbeddedItemEditor` hand it to `SchemaForm` are gone.
+
+No change for any form none of whose sections carries a `group` key: the resolver returns such a list by identity. A section carrying both `fields` and `group`, a shape `@objectstack/spec` refuses at parse, now takes the resolver's answer for its `group` (in a metadata-type editor, an empty section and the same `console.error`) instead of rendering its enumerated `fields`.

.changeset/9242-stray-kanban-groupby-lane-second-route.md

@@ -40,6 +40,18 @@ storage nor one that never passes through a validator, so what this change
 repairs is a pure **behaviour** gap, on any document that reaches this branch
 carrying the key.
 
+⚠️ **Dated note, 2026-09-28 — the named-view route's two faces have since changed —
+objectui#7928.** Later in this same release a named view became the protocol's strict
+`ObjectListViewSchema` record, by reference, on both faces. On the zod face the
+objectui#10321 door adds its message at `listViews.KEY.kanban.groupBy` only: the record
+refuses the `options` bag whole (`options` by name), so "refuses the key in either
+nesting with the same message" no longer holds. On the TypeScript face a named view's
+`kanban` is typed as the protocol's kanban block, not the `list-view`'s: `tsc` still
+refuses `kanban.groupBy` there, as an excess property on an object literal rather than a
+`never` member, and it now refuses the `options` bag itself. The `list-view` route is
+unchanged on both faces. `.changeset/7928-listviews-by-reference-fold.md` (PR
+objectui#10821) states what ships; the text above is kept as the reading of this change.
+
 Maintainer ruling of 2026-09-12 (decision batch #117 item 5, verbatim
 「8365 同意」) — option B. Option A (strip the key and silently re-group) was not
 taken. This card applies that ruling to the second route; it re-opens nothing.