docs(changelog): correct three false sentences in the published 17.3.0 release text — the reversed depends_on justification and the ListView binding paragraph in both CHANGELOGs (#16881)

* docs(changelog): correct three false sentences in the published 17.3.0 release text

Two cards were filed against pending .changeset/*.md files. A release consumed
both, so the false prose now lives in packages/spec/CHANGELOG.md and
packages/lint/CHANGELOG.md, which ship to npm inside the tarballs (CHANGELOG.md
is listed in files[] for both packages). Released CHANGELOG text is treated as
release-owned, so this is a dedicated docs-only PR riding on no code change.

Card 15058, packages/spec/CHANGELOG.md. The option-description bullet justified
not declaring dependsOn with "the canonical field-level depends_on already
exists". That is backwards. @objectstack/spec declares dependsOn, refuses
depends_on with a rename hint pointing the other way, and declares no
depends_on key anywhere. Measured at the entry's own commit 86e765a: git grep
for depends_on across packages/spec/src/**/*.zod.ts returns exactly one hit,
the false claim itself in a comment, against a positive control of six
dependsOn hits over three files at the same ref. So the claim was false when it
was written, not merely overtaken. The replacement matches the wording PR 15055
already landed at the source site in field.zod.ts rather than inventing a fifth
phrasing of the same fact.

Card 15026, both files, one byte-identical sentence in each. The 5383fa6 entry
told authors the lint accepts either ListView spelling as satisfying the
required binding, resolves field-name props against whichever is present, and
prefers canonical when both are. All three clauses are the other way round
today, and were already so at the moment this text shipped: 22b0081 landed
2026-09-03 and 8a1bad8 cut 17.3.0 on 2026-09-04, both ancestors of the cut
(git merge-base --is-ancestor, exit 0, with a control leg on 5383fa6 also
exit 0). Measured in packages/lint/src/validate-react-page-props.ts on this
tree: boundObjectName reads objectName only; objectProviderBindsNothing makes a
provider:'object' data binding fail the required binding; and the docblock
states the renderer reads objectName when an author writes both. Step 3 of the
ruling, which retires the aliases, has not landed - card 14791 is open and the
UNFOLDED_DEPRECATIONS set it deletes is still present, so the corrected text
says objectName / viewType remain the spellings to write.

Both corrections keep the true half of each sentence and preserve the record of
what shipped, naming the card that moved the fact - the shape PR 16856 and
PR 16874 used on the same file family. Nothing is restated as though it had
always been so.

Docs-only: the diff touches two files and three lines. Zero paths under
content/docs/releases/ (grep count 0 exit 1, with a positive control of 2 on
^packages/ over the same pipeline, and that directory holds 10 entries). No
code, no test, no changeset. No test or gate parses CHANGELOG.md content; the
two that name it exclude it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016N6xmWt5hYm94ffVEwGH8x

* docs(changelog): attach the ListView retirement to the artifact that carries it, and reconcile the entry's closing sentence

Seat finding on the draft: the corrected ListView paragraph said "retiring the
aliases is step 3 of this ruling, unlanded and still open as 14791", which
understated the state and left the paragraph contradicting its own closing
sentence ("Removal of the deprecated aliases is a later card after the
deprecation window") - one paragraph making two incompatible claims about
whether that card exists.

Measured rather than assumed, because two sources disagreed. Card 14791's TITLE
is the renderer-half finding, but the maintainer ruled option B ON that card on
2026-09-07 (comment 5572008848, verbatim "同意"): "step 3 retires objectName /
viewType on the ListView block now; no deprecation window". It was dispatched
2026-09-08T02:36Z and implemented as PR 16777, "feat(spec)!: retire the
ListView objectName / viewType react-tier aliases - data / type are the only
spellings", read from the API as open, draft, head 5b010e0, awaiting a
maintainer merge because it touches governed skills/**. So 14791 is both, and
naming the PR gives a reader the precise artifact instead of a title about
something else.

Also measured, and it falsified the other half of the old clause: the renderer
fold has already landed. At the pinned .objectui-sha 53ded82bf, git grep for
"provider === 'object'" in packages/core/src/utils/normalize-list-view.ts
returns 2 hits, exit 0 - :263 is a comment and :315 is the substantive fold
(dataConfig?.provider === 'object' && typeof dataConfig.object === 'string'),
the trap card 14791 names in its own body. Positive control at the same pin:
normalizeListViewSchema, 1 hit. So "until the renderer folds the canonical data
source in" was no longer a pending condition and is dropped.

The closing sentence is corrected under the bounded in-place exemption, all
four conditions holding: same defect class as this card (a false sentence in
this exact published entry), mechanical and in the register already pinned by
this PR, no other claim holds these files, and no new verification surface. It
is declared in the PR body rather than left silent.

Both copies moved together - the replacement is byte-identical in
packages/spec/CHANGELOG.md and packages/lint/CHANGELOG.md, sha1
482ecf56686847ed419e482c75ed04dde917bcc0, cmp exit 0, 1899 bytes. Fixing one
and leaving the other is this card's signature failure mode. Still docs-only:
2 files, +3/-3, zero paths under content/docs/releases/.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016N6xmWt5hYm94ffVEwGH8x

---------

Co-authored-by: Claude <noreply@anthropic.com>

Author: claude[bot]

packages/lint/CHANGELOG.md

@@ -433,7 +433,7 @@
 
   No `packages/spec` change — the page surface stays closed, which is what ADR-0047
   §7 open question 3 asks for.
-- 5383fa6: React-tier vocabulary converges on the metadata-tier spelling, deprecate-first (#11284, maintainer ruling 2026-08-23). `<ListView>`'s canonical bindings are now the spec ListView schema's own props: `data={{ provider: 'object', object: '…' }}` for the object binding (objectui#2890 A6) and `type` for the visualization kind. `objectName` and `viewType` remain published and accepted as deprecated aliases for the whole deprecation window — nothing is removed in this release — with the deprecation visible at authoring time: `[DEPRECATED → …]` markers in the generated react-blocks contract, and a new `react-prop-deprecated` lint warning (never an error) on every use of a deprecated spelling. The lint accepts either spelling as satisfying `<ListView>`'s required binding and resolves field-name props (`columns`, `searchableFields`, filter positions, …) against the object bound by whichever spelling is present, canonical winning when both are. `<ObjectForm>` / `<ObjectChart>` `objectName` are unchanged: the form's spec counterpart is explicitly not 1:1 (objectui#2890 Scope B), and the chart has no metadata-tier object binding to converge on (charts bind through a dashboard `dataset` there — see chart.zod.ts guidance). Removal of the deprecated aliases is a later card after the deprecation window.
+- 5383fa6: React-tier vocabulary converges on the metadata-tier spelling, deprecate-first (#11284, maintainer ruling 2026-08-23). `<ListView>`'s canonical bindings are now the spec ListView schema's own props: `data={{ provider: 'object', object: '…' }}` for the object binding (objectui#2890 A6) and `type` for the visualization kind. `objectName` and `viewType` remain published and accepted as deprecated aliases for the whole deprecation window — nothing is removed in this release — with the deprecation visible at authoring time: `[DEPRECATED → …]` markers in the generated react-blocks contract, and a new `react-prop-deprecated` lint warning (never an error) on every use of a deprecated spelling. The lint accepted either spelling as satisfying `<ListView>`'s required binding and resolved field-name props (`columns`, `searchableFields`, filter positions, …) against the object bound by whichever spelling is present, canonical winning when both are — true at this entry's own commit `5383fa6`, and already false in the release that published it. `22b0081` (#15025) landed before the 17.3.0 version cut and tightened the lint back to what actually renders, so as released here every clause is the other way round: a `<ListView>` bound only by `data={{ provider: 'object', object }}` does NOT satisfy the required binding and `os validate` refuses it, field-name props resolve against `objectName` only, and `objectName` is the spelling that decides when a page carries both, because it is the one the renderer queries. `objectName` / `viewType` are therefore the spellings to write. `<ObjectForm>` / `<ObjectChart>` `objectName` are unchanged: the form's spec counterpart is explicitly not 1:1 (objectui#2890 Scope B), and the chart has no metadata-tier object binding to converge on (charts bind through a dashboard `dataset` there — see chart.zod.ts guidance). Removal of the deprecated aliases was described here as a later card after the deprecation window; that is no longer the plan. The maintainer ruling of 2026-09-07 on #14791 — the card that measured the missing consumer half — retires `objectName` / `viewType` with no deprecation window at all, leaving `data` / `type` as the only spellings. objectui has since landed the renderer fold the canonical spelling needed (present at the pinned `.objectui-sha`, `packages/core/src/utils/normalize-list-view.ts`), and the spec-side retirement is authored as PR #16777, still draft and awaiting a maintainer merge — so within this release the deprecated spellings remain the working ones. (Corrected after publication, #15026.)
 - 46b53a2: Add `validateReadonlyActionWrites` — an author-time warning on an action body writing a `readonlyWhen` field through `ctx.api`.
 
   The action surface is the third write surface in the readonly family, after `flow-update-readonly-field` and `hook-api-update-readonly-field`, and it is the one where the family's answer differs. An action body's `ctx.api` is `createContext({ ...callerEnvelope, isSystem: true })` — elevated by design, so RLS/FLS-bypassing trusted execution is the documented posture — and the engine's **static** readonly strip runs only for non-system callers. Measured against a real engine over a memory driver:

packages/spec/CHANGELOG.md

@@ -1494,7 +1494,7 @@
   Both keys were consumed-but-undeclared — real behaviour in the running app, reached through an `as any` on the metadata carrier, while the strict publish door refused exactly the author who wrote them legally:
 
   - `rows?: number` (positive integer) on the multiline editor types `textarea` / `markdown` / `html` / `richtext`. objectui's `RichTextField` — the one widget behind the `markdown`/`html`/`richtext` registry keys — reads `richField?.rows || 8`, and `TextAreaField` reads `textareaField?.rows || 4`, sizing the inline (non-fullscreen) editor surface. The ruled pair is `markdown`/`html` (aligning the `TextareaFieldMetadata` precedent); `textarea`/`richtext` complete the measured consumption set. A superRefine refuses the key on every other type (the #11566 template), and the house count discipline refuses `0` / negative / fractional values. Both authoring forms show the key for exactly this set. The ruling's capability expansion STOPS here: the four inert rich-text editor keys (`toolbar`/`preview`/`minHeight`/`maxHeight`) stay undeclared, and a pin holds that door shut.
-  - `description?: string` on `SelectOptionSchema`. objectui's `LookupField` searches it on a lookup's authored static options (`opt.description && opt.description.toLowerCase().includes(q)`) and its `recordToOption` produces the same key for fetched options — and the object-definition authoring form has offered a `description` input all along; the declaration makes both honest. It flows into `FormSelectOptionSchema` by the #12868 Omit construction. Per the same inherited ruling, `dependsOn` is deliberately NOT declared — the canonical field-level `depends_on` already exists, and the widget-side spelling fix rides the objectui half.
+  - `description?: string` on `SelectOptionSchema`. objectui's `LookupField` searches it on a lookup's authored static options (`opt.description && opt.description.toLowerCase().includes(q)`) and its `recordToOption` produces the same key for fetched options — and the object-definition authoring form has offered a `description` input all along; the declaration makes both honest. It flows into `FormSelectOptionSchema` by the #12868 Omit construction. Per the same inherited ruling, `dependsOn` is deliberately NOT declared on this option shape — it declares `description` and no cascade key of its own. As published, this sentence justified that by "the canonical field-level `depends_on` already exists"; that was false when written and is false now — `@objectstack/spec` declares no `depends_on` key, at this entry's own commit `86e765a` or since. The cascade key this package declares is the camelCase `dependsOn` on `FieldSchema`, which refuses the snake_case `depends_on` with a rename hint; `depends_on` is objectui's own consumer-side `BaseFieldMetadata` spelling, which mirrors it (maintainer ruling 2026-09-02 on objectui#6153). PR #15055 rewrote the same claim at its source in `field.zod.ts`. (Corrected after publication, #15058.)
 
   Additive in both cases: no stored shape changes, and every previously-written body carrying either key was refused at parse, so nothing legal changes meaning.
 - 1d7e76a: feat(spec): `Field.valueDomain` — one closed standard-domain vocabulary and one membership predicate shared by settings specifiers and object fields (maintainer ruling 2026-09-02 on #14168, spec half)
@@ -3638,7 +3638,7 @@
   alone would strand it and the set-narrowing option becomes required.
 
   <!-- adr-0087: not-required (no-migration-prescription) The ruling explicitly declines a migration: at-rest data keeps its read path via the untouched MULTI_CAPABLE_TYPES / isMultiValueField, and re-measurement at the merge base found zero occurrences of the refused combination in either repo, so there is no existing author to migrate and nothing objectstack migrate meta is authorized to rewrite — a conversion rewriting the pair would itself be the stored-shape migration Option C was chosen to avoid. Guidance for future authors lives in the refusal diagnostic itself. -->
-- 5383fa6: React-tier vocabulary converges on the metadata-tier spelling, deprecate-first (#11284, maintainer ruling 2026-08-23). `<ListView>`'s canonical bindings are now the spec ListView schema's own props: `data={{ provider: 'object', object: '…' }}` for the object binding (objectui#2890 A6) and `type` for the visualization kind. `objectName` and `viewType` remain published and accepted as deprecated aliases for the whole deprecation window — nothing is removed in this release — with the deprecation visible at authoring time: `[DEPRECATED → …]` markers in the generated react-blocks contract, and a new `react-prop-deprecated` lint warning (never an error) on every use of a deprecated spelling. The lint accepts either spelling as satisfying `<ListView>`'s required binding and resolves field-name props (`columns`, `searchableFields`, filter positions, …) against the object bound by whichever spelling is present, canonical winning when both are. `<ObjectForm>` / `<ObjectChart>` `objectName` are unchanged: the form's spec counterpart is explicitly not 1:1 (objectui#2890 Scope B), and the chart has no metadata-tier object binding to converge on (charts bind through a dashboard `dataset` there — see chart.zod.ts guidance). Removal of the deprecated aliases is a later card after the deprecation window.
+- 5383fa6: React-tier vocabulary converges on the metadata-tier spelling, deprecate-first (#11284, maintainer ruling 2026-08-23). `<ListView>`'s canonical bindings are now the spec ListView schema's own props: `data={{ provider: 'object', object: '…' }}` for the object binding (objectui#2890 A6) and `type` for the visualization kind. `objectName` and `viewType` remain published and accepted as deprecated aliases for the whole deprecation window — nothing is removed in this release — with the deprecation visible at authoring time: `[DEPRECATED → …]` markers in the generated react-blocks contract, and a new `react-prop-deprecated` lint warning (never an error) on every use of a deprecated spelling. The lint accepted either spelling as satisfying `<ListView>`'s required binding and resolved field-name props (`columns`, `searchableFields`, filter positions, …) against the object bound by whichever spelling is present, canonical winning when both are — true at this entry's own commit `5383fa6`, and already false in the release that published it. `22b0081` (#15025) landed before the 17.3.0 version cut and tightened the lint back to what actually renders, so as released here every clause is the other way round: a `<ListView>` bound only by `data={{ provider: 'object', object }}` does NOT satisfy the required binding and `os validate` refuses it, field-name props resolve against `objectName` only, and `objectName` is the spelling that decides when a page carries both, because it is the one the renderer queries. `objectName` / `viewType` are therefore the spellings to write. `<ObjectForm>` / `<ObjectChart>` `objectName` are unchanged: the form's spec counterpart is explicitly not 1:1 (objectui#2890 Scope B), and the chart has no metadata-tier object binding to converge on (charts bind through a dashboard `dataset` there — see chart.zod.ts guidance). Removal of the deprecated aliases was described here as a later card after the deprecation window; that is no longer the plan. The maintainer ruling of 2026-09-07 on #14791 — the card that measured the missing consumer half — retires `objectName` / `viewType` with no deprecation window at all, leaving `data` / `type` as the only spellings. objectui has since landed the renderer fold the canonical spelling needed (present at the pinned `.objectui-sha`, `packages/core/src/utils/normalize-list-view.ts`), and the spec-side retirement is authored as PR #16777, still draft and awaiting a maintainer merge — so within this release the deprecated spellings remain the working ones. (Corrected after publication, #15026.)
 - 5b3ff63: feat(spec,rest): register `READ_BACK_FAILED` as a named wire row and map it in `handleApprovalError` (#13182)
 
   The `READ_BACK_FAILED:` refusal (#12769: an approval mutation succeeded but its