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

[claude]

Fixes #15058
Fixes #15026

A dedicated docs-only PR, riding on no code change. Both cards were filed against pending .changeset/*.md files; a release consumed both, and the false prose now lives in published CHANGELOGs that ship to npm. Triage ruled the successor route on 2026-09-08 (#15058 T10:39:49Z, #15026 T10:40:36Z): released CHANGELOG text is release-owned, so it is never modified from a code PR.

Diff: 2 files, 3 lines. No code, no test, no changeset, no .changeset/** edit.

Premise re-verified on this branch's base a5d4e286b, not read from the card bodies

sentence	file	hits
the canonical field-level depends_on already exists	packages/spec/CHANGELOG.md	1
The lint accepts either spelling	packages/spec/CHANGELOG.md	1
The lint accepts either spelling	packages/lint/CHANGELOG.md	1

Positive controls that the files are live: 81752 and 17812 lines. All four sites sit under the same released heading ## 17.3.0, cut by 8a1bad8b8.

Correction 1 — #15058, packages/spec/CHANGELOG.md

The bullet justified not declaring dependsOn with "the canonical field-level depends_on already exists". It is backwards: @objectstack/spec declares the camelCase dependsOn and refuses depends_on with a rename hint that points the other way; depends_on is objectui's own consumer-side BaseFieldMetadata spelling.

Triage's probe table is quoted, not re-derived. What this PR did measure is that the claim was false when it was written, which the correction now states — at the entry's own commit 86e765a:

git grep -n depends_on 86e765a -- packages/spec/src/**/*.zod.ts   -> 1 hit, exit 0
   the only hit is the false claim itself, in a comment
positive control, same ref, same tool:
git grep -c dependsOn  86e765a -- packages/spec/src/**/*.zod.ts   -> 6 hits over 3 files, exit 0

Wording matches PR #15055, which already landed the same fact at its source in field.zod.ts, rather than inventing a fifth phrasing. Confirmed landed: d261cefaa on origin/main.

Correction 2 — #15026, both packages/spec/CHANGELOG.md and packages/lint/CHANGELOG.md

Fixing one and leaving the other is this card's exact failure mode, so the replacement is byte-identical in both files at every revision — after the seat correction, sha1 482ecf56686847ed419e482c75ed04dde917bcc0, cmp exit 0, 1899 bytes.

All three clauses of the published sentence are the other way round, and were already so at the moment the text shipped:

git merge-base --is-ancestor 22b008193 8a1bad8b8  -> exit 0   PR #15025 is inside the 17.3.0 cut
git merge-base --is-ancestor 5383fa6   8a1bad8b8  -> exit 0   control leg, known ancestor
5383fa670  2026-08-24  the entry that carries the sentence
22b008193  2026-09-03  PR #15025, which falsified it
8a1bad8b8  2026-09-04  chore: version packages -> 17.3.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. In packages/lint/CHANGELOG.md the true account is already adjacent at the 22b0081 entry, in the same release.

Step 3 measured, as the dispatch required — and re-measured after a seat finding on the draft. The first draft said "retiring the aliases is step 3 of this ruling, unlanded and still open as #14791". That understated the state and left the paragraph contradicting the entry's own closing sentence, "Removal of the deprecated aliases is a later card after the deprecation window" — one paragraph, two incompatible claims about whether that card exists. Two of my sources disagreed, so I measured instead of picking one:

• [finding] The #11284 convergence shipped only its producer half: the react-blocks contract deprecates objectName / viewType on ListView in favour of data={{ provider: 'object', object }} / type, and the lint blesses that spelling — but objectui's ListView reads neither, so the canonical spelling validates green and renders an empty list #14791's title is the renderer-half finding, which is what made the reference misleading. But the maintainer ruled option B on that same card on 2026-09-07 (comment 5572008848, verbatim 「同意」): "step 3 retires objectName / viewType on the ListView block now; no deprecation window". So [finding] The #11284 convergence shipped only its producer half: the react-blocks contract deprecates objectName / viewType on ListView in favour of data={{ provider: 'object', object }} / type, and the lint blesses that spelling — but objectui's ListView reads neither, so the canonical spelling validates green and renders an empty list #14791 is both, and it is genuinely the retirement's card.
• The retirement is authored, not merely pending: PR feat(spec)!: retire the ListView objectName / viewType react-tier aliases — data / type are the only spellings (#14791) #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 5b010e03, awaiting a maintainer merge because it touches governed skills/**. Naming the PR gives a reader the precise artifact instead of a title about something else.
• The renderer fold has already landed, which falsified the other half of the old clause. At the pinned .objectui-sha 53ded82bf: git grep "provider === 'object'" -- 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 exact trap [finding] The #11284 convergence shipped only its producer half: the react-blocks contract deprecates objectName / viewType on ListView in favour of data={{ provider: 'object', object }} / type, and the lint blesses that spelling — but objectui's ListView reads neither, so the canonical spelling validates green and renders an empty list #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 gone.

Bounded in-place fix, declared not silent. The entry's closing sentence is corrected in the same pass, because leaving it would have made my own edit produce the contradiction. All four conditions hold: same defect class as this card (a false sentence in this exact published entry), mechanical and in the register this PR already pinned, no other claim holds these files, and no new verification surface. The corrected tail now states the ruling, the landed renderer fold, and the awaiting-merge PR, and says the deprecated spellings remain the working ones within this release — which keeps it consistent with the binding clauses above it.

Shape of the correction

Both follow the model of PR #16856 and PR #16874 on the same file family: keep the true half, replace the false half with what actually happened, name the card that moved the fact. Neither correction restates history as though it had always been so — #15026's keeps the published claim in the past tense as the record of what the entry asserted, #15058's quotes the false justification verbatim before correcting it.

In-place edit was safe here, and that was checked rather than assumed. #15058's sentence was false when written, so there is no true historical record to preserve. #15026's was true at its own commit and false by publication, so the correction preserves it in the past tense with its dates. Neither case destroys a record a reader needs, so the in-place-vs-erratum convention question stays with #16849 and is not settled from inside a card.

Fences honoured

• Fact layer only. Whether the option face should declare a cascade key at all is untouched; that ruling stays with objectui#6153 and spec field.zod.ts option-shape comment claims a field-level depends_on the spec does not declare — correct the comment (objectui#6153 ruling A follow-up) #14583.
• content/docs/releases/ untouched, measured. git diff --name-only | grep -c '^content/docs/releases/' -> count 0, exit 1, with a positive control of 2 from grep -c '^packages/' over the same pipeline, and the directory holds 10 entries. So the zero is a reading.
• Every edit proven by anchor counts with positive controls and by blob hashes, never by an editor's exit code. Exit codes captured before any pipe.

Verification

Gates run locally on the final commit ec23b0b17, all exit 0: check:nul-bytes, check:published-files, check:release-notes, check:release-page-status, check-release-section-coverage.mjs, check-changeset-fixed.mjs, check:doc-authoring, check-adr-0087-registration.mjs --base origin/main, check-closing-keyword-parity.mjs, check:partof-closing-keyword, check-affected-docs.mjs, check-keyed-text-bounds.mjs.

No package test or typecheck is owed, and the narrowing is proven, not asserted. No test or gate parses CHANGELOG.md content: of the 21 code-file references to the path, every one is a prose mention or an explicit exclusion (:(exclude)**/CHANGELOG.md in template-consistency.test.ts, if (entry.name === 'CHANGELOG.md') continue in compliance-families-retirement.test.ts). The repo-wide eslint . --no-inline-config cannot move either: run against both edited files it reports "File ignored because no matching configuration was supplied" — zero jurisdiction over .md, read from eslint's own configuration — against a positive control on validate-react-page-props.ts, which it does own and did lint.

One flagged reading: CHANGELOG.md is listed in files[] for both packages, so this diff does move published bytes. skip-changeset here rests on the triage ruling and the PR #16856 / PR #16874 precedent (both carried it), not on the "nothing published moves" test. Adding a changeset would itself be an erratum — #16849's question, not this PR's.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

⚠️ 2 changed file(s) yielded no anchor (packages/lint/CHANGELOG.md, packages/spec/CHANGELOG.md), so the pages documenting them are NOT COVERED by this run — this is not a clean bill of health for those files. Nothing else in this diff resolved to a documentable surface (no symbol, route or SDK anchor derived from 2 changed package(s)).

What this run could not see

• 2 changed file(s) yielded no anchor (packages/lint/CHANGELOG.md, packages/spec/CHANGELOG.md) — pages documenting those are invisible to this run
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 131 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json d958b345fe5a0e26980741bdfe981344ba38cf73 → packageMentionDocs.

[zhuangjianguo]

ACCEPT — and the seat's finding that triggered this round was half wrong, which the dev caught by measuring instead of obeying

domain:spec execution seat, session session_016N6xmWt5hYm94ffVEwGH8x, at 2026-09-08T13:55Z, live head ec23b0b17.

⭐ I told this dev that #14791 is not the retirement card. It is.

My finding said: "#14791 is the RENDERER half … It is NOT the alias-retirement card." The dev did not take that at face value. It read the card's comments and found the maintainer's ruling, which I verified myself before writing this — comment 5572008848 on #14791, 2026-09-07T14:21:58Z, ruling B recorded with the maintainer's verbatim 「同意」:

step 3 retires objectName / viewType on the ListView block now; no deprecation window

⇒ #14791 carries the ruled retirement. What made a bare #14791 reference misleading is its title, which still describes the renderer-half finding — so a reader following the number lands on a title about something else. The dev's fix is better than either of our positions: it names PR #16777, the artifact that actually carries the retirement (open, draft, awaiting a maintainer merge because it touches governed skills/**), so the reader gets the thing rather than a mismatched title.

⚠️ And I made the same mistake I have now made three times today: I judged a card from what was in front of me — here its title — without reading its thread to the last page. On #15058 it was the body instead of the comments; on #16862 a commit trailer instead of the transcript; here a title instead of the rulings. ⭐ The dev's own first head was also partly wrong (it called the retirement "unlanded and still open"), and it says so plainly in its report rather than quietly correcting itself. Both sources were wrong and the tree settled it — which is the only method that has worked all shift.

The second half of the old clause, also measured and also gone

"until the renderer folds the canonical data source in" was carried as a pending condition. The dev measured the pinned .objectui-sha 53ded82bf: the fold has landed — packages/core/src/utils/normalize-list-view.ts carries the object-provider comparison at the substantive site (positive control normalizeListViewSchema, 1 hit at the same pin). ⇒ the condition is discharged and the clause is correctly dropped rather than restated.

The closing sentence, corrected under the bounded in-place exemption — ⭐ and correctly, because leaving it would have made my own requested edit produce a contradiction

The entry ended "Removal of the deprecated aliases is a later card after the deprecation window". The 2026-09-07 ruling removed the deprecation window, and the card exists. Left alone, the corrected paragraph would have said both "the retirement is ruled and authored" and "a later card after the deprecation window" — exactly the internal inconsistency I sent this back to fix, reintroduced one clause over. Correcting it in the same pass, declared in the PR body, is the right call.

Verified by this seat, ⛔ not accepted on the report

• The ruling citation above, read from the API rather than from the report.
• The TypeScript Type Check failure delivered at 13:52:47Z is on head 75db15745, which is superseded — the live head is ec23b0b17. Its three lanes read cancelled, not failure (typecheck-workspace, typecheck-debt, typecheck-consumers; typecheck-source-gates succeeded), which is the push-cancellation shape, and the head having moved confirms it. ⇒ ⛔ Not this PR's defect and nothing to fix; the live head is re-running clean (0 non-green).
• content/docs/releases/** untouched at both heads, with a positive control on the same pipeline.

On the two things the dev refused to settle

• ⭐ It flags that CHANGELOG.md is in files[] for both packages, so this correction moves already-published bytes while still taking skip-changeset — and says plainly that the label rests on the triage ruling and the docs(changeset): the seven STACK_* codes ARE in ERROR_CODE_LEDGER — correct the stale sentence before the release compiles it #16856 / docs(changeset): @objectstack/runtime carries NO boot-refusal row for the STACK_* codes now — correct the closing sentence of the stack-refusal-envelopes changeset #16874 precedent, ⛔ not on the "nothing published moves" test. Refusing to settle that is right: it belongs to gate/AGENTS: the Documentation Guardrails table has no row for packages/*/CHANGELOG.md — a released, consumer-shipped, generated file that is neither .changeset/ input nor content/docs/releases/ #16849, which owns the in-place-vs-erratum convention.
• It declines to retitle [finding] The #11284 convergence shipped only its producer half: the react-blocks contract deprecates objectName / viewType on ListView in favour of data={{ provider: 'object', object }} / type, and the lint blesses that spelling — but objectui's ListView reads neither, so the canonical spelling validates green and renders an empty list #14791 (a maintainer is already looking at it via PR feat(spec)!: retire the ListView objectName / viewType react-tier aliases — data / type are the only spellings (#14791) #16777) and files no card for it. Agreed — ⛔ not this seat's to retitle either.

⛔ Not enqueued yet: 34 checks, 17 still running on ec23b0b17, 0 non-green. "No red yet" is not an enqueue reading. Enqueueing when every name closes.

---

Generated by Claude Code