docs(changeset): correct six pending changesets whose surrounding claims a later merge falsified (objectui#9065)

.changeset/5293-view-sort-order-spelling.md

@@ -32,15 +32,20 @@ was dropped at three independent readers rather than rejected at one. This renam
 take away a feature — it converts a silent wrong answer into a loud type error at the one
 place that can still be fixed cheaply.
 
-**Scope — one published export still accepts `direction`, and this release does not retire
-it.** `toSortItems` (`packages/plugin-view/src/config/view-config-utils.ts`, re-exported
-from the package root and listed in the README) folds `s.order || s.direction || 'asc'`.
-It serves a different surface — the studio inspector-draft that feeds `SortBuilder` — and
-it is not reachable from the `views` prop, so it neither affects nor is affected by this
-rename. If you migrate by searching for the old key, that is the other hit you will find:
-it is dormant (nothing in this repo calls it outside a test), and removing it would be a
-separate break on a separate public export, tracked as objectui#6011. It is not a partial
-retirement of this one.
+**Scope — at this change one other published export still accepted `direction`, and this
+release did not retire it.** `toSortItems` (`packages/plugin-view/src/config/view-config-utils.ts`,
+re-exported from the package root and listed in the README) folded
+`s.order || s.direction || 'asc'`. It serves a different surface — the studio
+inspector-draft that feeds `SortBuilder` — and it is not reachable from the `views` prop,
+so it neither affected nor was affected by this rename: dormant (nothing in this repo
+called it outside a test), and removing it would be a separate break on a separate public
+export, tracked as objectui#6011. It was not a partial retirement of this one.
+
+⚠️ **That second export has since been retired too — objectui#6011.** `toSortItems` now
+reads `order`, and only `order`: a draft entry still spelled `{ field, direction }` takes
+the `'asc'` default instead of the direction it asked for. So the migration search
+described above no longer finds a live `direction` read on this package's published sort
+path.
 
 `order` is the spelling every other sort surface already uses (`SortConfig`,
 `NamedListView.sort`, `ObjectGridSchema.sort` / `.defaultSort`, and the shared

.changeset/7165-grid-dependent-values.md

@@ -23,8 +23,15 @@ and the grid never got it. `renderCellEditor` now passes
 `dependentValues={ctx.row}`, supplying that missing input; no cascade is
 re-implemented.
 
-⚠️ Interim, and deliberately labelled as such in the code (#7165): `ctx.row` is
-the **saved** record, so a parent edited but not yet saved in the same row does
-not re-scope the child — it stays scoped by the persisted value. Matching the
-form's live-record semantics needs a new member on `renderCellEditor`'s
-published context type and is tracked as #7188.
+⚠️ Interim at this change, and deliberately labelled as such in the code
+(#7165): `ctx.row` is the **saved** record, so a parent edited but not yet saved
+in the same row did not re-scope the child — it stayed scoped by the persisted
+value. Matching the form's live-record semantics needed a new member on
+`renderCellEditor`'s published context type, tracked as #7188.
+
+✅ **#7188 has since landed, and that limitation is gone.** `renderCellEditor`'s
+context now carries the row twice — `row` is still the persisted record and
+`pendingRow` is that record with the row's staged, unsaved edits merged over it —
+and the grid passes `dependentValues={ctx.pendingRow ?? ctx.row}`. A parent
+picked but not yet saved re-scopes the child immediately, which is the form's
+semantics.

.changeset/7655-chatbot-registration-authoring-faces.md

@@ -38,11 +38,14 @@ per key on the PR's base (one `schema.KEY` read per registration body in
   plus `enableMarkdown`, `enableFileUpload`, `onClear`, and the two keys it
   declares alongside `ChatbotSchema` — `floatingConfig` (`FloatingChatbotConfig`)
   and `displayMode`. No `maxHeight`, `processVisibility` or `surface`: the
-  floating registration has no named read for any of them. (Its trailing raw
-  props spread does carry authored keys into the panel today — `processVisibility`,
-  `surface` and `showAvatars` are live there, measured through the real host;
-  that accidental channel is tracked as objectui#7708, and this face neither
-  declares nor promises it.)
+  floating registration has no named read for any of them. (At this change its
+  trailing raw props spread still carried authored keys into the panel —
+  `processVisibility`, `surface` and `showAvatars` were live there, measured
+  through the real host — and this face neither declared nor promised that
+  accidental channel, which was tracked as objectui#7708. That card has since
+  fenced the spread the way the two sibling registrations do, so those three keys
+  are dark on `chatbot-floating` now; no member this face declares depended on
+  the channel.)
 - Neither face declares `ChatbotSchema`'s six legacy members (`loading`,
   `showAvatars`, `userAvatar`, `assistantAvatar`, `markdown`, `height`) — no
   registration reads them by name — and neither redeclares `disabled`, which

.changeset/7727-conditional-formatting-record-scope.md

@@ -123,10 +123,17 @@ flattened.
 - **The `data.*` half.** Dropping `'data'` from `ROW_PREDICATE_ROOTS` stops
   *recommending* it; it does not stop the lint *accepting* it.
   `@objectstack/formula`'s `SCOPE_ROOTS` lists `data`, so `data.status == 'x'` still
-  lints clean at `scope:'record'` while resolving against the host's ambient `data`
-  rather than the row — constant-false, silently. Pinned here as a characterization
-  test, tracked as objectui#8166. This changeset closes the **bare-field** half of the
-  retirement only.
+  lints clean at `scope:'record'` — and at this change it also still RESOLVED, against
+  the host's ambient `data` rather than the row, constant-false and silently. Pinned
+  here as a characterization test, tracked as objectui#8166. This changeset closes the
+  **bare-field** half of the retirement only.
+
+  ⚠️ **objectui#8166 has since closed the half this repo owns.** `buildExpressionScope`
+  no longer binds an ambient `data` on record surfaces, so such a condition now FAULTS
+  with the engine's own `Unknown variable: data` instead of resolving constant-false.
+  The lint still accepts the spelling — narrowing `SCOPE_ROOTS` is the producer-side
+  half and lives in `@objectstack/formula` — so what moved is the silence, not the
+  accept set.
 
 ⛔ And this editor is **not** the last authoring site still on the flattened default —
 `ConditionBuilder` reaches it by passing no `scope` at all, which is why a grep for the

.changeset/8253-export-tree-view-config.md

@@ -35,15 +35,28 @@ re-writes.
   of the exported one and the resolver's own type is `Pick`ed off it. No runtime
   behaviour changes, and no key is added to or removed from what the renderer reads.
 
-**`titleField` is declared, not deleted — and that was a measurement.** The ruling put
+**`titleField` was declared, not deleted — and that was a measurement.** The ruling put
 this key to a test: declare it if the console writes it, else remove the read. The
 console's create-view dialog does **not** offer it (its `tree` slot collects
 `parentField` alone), but the console's own host composition reads it by name, so do
-the `ListView` and `ObjectView` tree branches, and the rung is pinned as live behaviour
-by objectui#6557 ("the tree's second view-declared rung … still answers"). Deleting the
-read would have reversed a recorded ruling and reddened its pin. Declaring it makes
-declared = enforced at all four read sites at once. `labelField` remains canonical and
-wins wherever both are present.
+the `ListView` and `ObjectView` tree branches, and that rung is pinned as live behaviour
+by objectui#6557 ("the tree's second view-declared rung … still answers"). Deleting that
+read would have reversed a recorded ruling and reddened that pin, so this change declared
+the key at all four read sites instead. `labelField` remains canonical and wins wherever
+both are present.
+
+⚠️ **Superseded — the declaration has since been removed.** objectui#8841 (PR
+objectui#9052) settled it against the protocol rather than against the reads:
+`@objectstack/spec@17.4.0`'s `TreeConfigSchema` is a `strictObject` and refuses
+`titleField` on `ListView.tree` by name, so declaring it here published a key an author
+following `@object-ui/types` was refused for at publish. `TreeViewConfig` is now derived
+from that protocol block and no longer carries the key, and `plugin-tree`'s
+`?? schema.titleField` rung — which read the flattened NODE, not this block — went with
+it. ⛔ What did NOT go is the view-declared read objectui#6557 pins: the
+`labelField || titleField` dual-reads in `plugin-view`, `plugin-list` and the console
+survive as undeclared tolerance, so stored view records keep resolving and that pin is
+still green. Read this entry for why the key was declared and objectui#8841's for why the
+declaration could not stand; the migration is to write `tree.labelField`.
 
 **Migration.** None required. Hosts that already compose a `tree` block keep working;
 hosts that annotate one against `TreeViewConfig` start getting a compile error for a

.changeset/8934-chatter-feed-affordance-only.md

@@ -29,11 +29,14 @@ now names the spec symbol it delegates to.
 **Defaults come with the shape, and two of them are visible.** This applies to
 an **authored `record:chatter` / `record:discussion` block**, and to every
 synthesized default page (which emits `record:discussion`) — those are the
-surfaces that render through `RecordChatterRenderer`. The panel the host
-auto-appends when a page omits a discussion block mounts `RecordChatterPanel`
-directly and does **not** run this pipeline, so it is unchanged and now renders
-a different feed from the authored block on the same record; that divergence is
-filed as objectui#8983. On the surfaces this change does reach:
+surfaces that render through `RecordChatterRenderer`. At this change the panel
+the host auto-appends when a page omits a discussion block mounted
+`RecordChatterPanel` directly and did **not** run this pipeline, so it was
+unchanged and rendered a different feed from the authored block on the same
+record; that divergence was filed as objectui#8983 and has since been closed —
+the fallback now mounts this renderer with no schema, so both chatter surfaces
+run the one pipeline and render the same feed. On the surfaces this change
+reaches:
 
 - `showCompleted` defaults to `false`, so **completed activities (feed type
   `task`) are no longer rendered** unless the block authors
@@ -49,8 +52,8 @@ no-filter.
 `enableMentions` are also members of the declared shape and are still unread on
 this path — `RecordActivityTimeline` takes `filterMode` as a component prop
 rather than off `config`, and the chatter path's mentions come from the host
-context. Tracked as objectui#8968. The host fallback panel described above is
-tracked as objectui#8983.
+context. Tracked as objectui#8968. The host fallback panel described above was
+tracked as objectui#8983, since closed — see the note above it.
 
 Marked `minor` rather than `patch`: this repository never declares `major` (the
 fixed release group would drag every package off `@objectstack`'s cadence), and