docs(fields): attribute option description to objectui, not to the spec

.changeset/6140-field-metadata-rows-option-description.md

@@ -9,15 +9,29 @@ the widget reads they legalize:
 
 - `MarkdownFieldMetadata.rows` and `HtmlFieldMetadata.rows` (`@object-ui/types`)
   — the inline-editor height `RichTextField` has always read through an
-  `as any` (default 8), aligned with the `TextareaFieldMetadata` precedent and
-  `@objectstack/spec` `FieldSchema.rows` (positive integer, multiline editor
-  types). The four inert editor keys (`toolbar`/`preview`/`minHeight`/
+  `as any` (default 8), following the `TextareaFieldMetadata` precedent. NOT a
+  spec key: `@objectstack/spec` `FieldSchema` refuses `rows` BY NAME
+  (`unrecognized_keys`) on all four of textarea/markdown/html/richtext, so it is
+  an objectui render hint that must not be written into authored object
+  metadata. The four inert editor keys (`toolbar`/`preview`/`minHeight`/
   `maxHeight`) stay deliberately undeclared and are pinned so.
 - `SelectOptionMetadata.description` — secondary option text `LookupField`
-  searches on authored static options and emits from `recordToOption`,
-  aligned with `@objectstack/spec` `SelectOptionSchema.description`.
+  searches on authored static options and emits from `recordToOption`. NOT a
+  spec key either: `@objectstack/spec` `SelectOptionSchema` is strict over
+  exactly `{label, value, color, default, visibleWhen}` and refuses
+  `description` BY NAME, and `FieldSchema` routes `options` through that schema,
+  so the key must never reach authored object metadata.
 - `RichTextField` and `TextAreaField` (`@object-ui/fields`) now read their
   metadata through the declared types instead of `field as any` (the spec-face
   `maxLength` dual-read in `TextAreaField` stays as a documented structural
   read). Behaviour unchanged; `rows` and option `description` are now legal to
-  author with an annotated literal.
+  author in an objectui **annotated literal** — never in an object document sent
+  to the platform.
+
+Both spec attributions above were corrected in place before release
+(objectui#7537): as first written this changeset claimed each key was "aligned
+with" a `@objectstack/spec` schema member that does not exist. Re-measured on
+`@objectstack/spec@17.2.0`, each refusal is paired with a control that accepts
+the same payload minus the key. Same correction as objectui#7014 / PR #7510 made
+to the published JSDoc; the package bumps and the declared behaviour are
+unchanged.

content/docs/fields/lookup.mdx

@@ -63,9 +63,17 @@ const priority: LookupFieldMetadata = {
 
 A static option may also carry a `description` — secondary text the picker's
 typeahead searches alongside the label. It is a declared `SelectOptionMetadata`
-member (declared for exactly that consumption —
-[objectui#6153](https://github.com/objectstack-ai/objectui/issues/6153) — and
-aligned with `@objectstack/spec`'s `SelectOptionSchema.description`). The
+member, declared for exactly that consumption
+([objectui#6153](https://github.com/objectstack-ai/objectui/issues/6153)), but it
+is an **objectui-side read-model extension, not a spec key**. Measured on the
+installed `@objectstack/spec`, `SelectOptionSchema` is strict over exactly
+`{label, value, color, default, visibleWhen}` and refuses `description` **by
+name** (`unrecognized_keys`), with the same option minus the key accepted as the
+control. `FieldSchema` routes a field's `options` through that schema, so
+authoring `description` on an option in an object document fails the **whole
+field** with a 422 — the key lives on the runtime read model the widget consumes
+and must never reach authored object metadata
+([objectui#7014](https://github.com/objectstack-ai/objectui/issues/7014)). The
 `dataSource` a host injects and the `onCreateNew` callback it passes are widget props,
 not metadata.