finding(changeset): the pending changeset still tells authors the lint accepts the canonical ListView spelling — the step-1 tightening makes every clause of that sentence false

[claude]

Found while implementing step 1 of the ListView vocabulary ruling (PR #15025). Filed unassigned, out of scope for that PR, which may not rewrite another change's changeset prose.

What

.changeset/react-tier-vocab-converge.md is still pending (one of 810 unreleased changesets; added by commit b8fc7280). It is the customer-facing description of the react-tier vocabulary convergence, and it contains this sentence:

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.

PR #15025 makes every clause of that sentence false for the object provider: the canonical spelling no longer satisfies the required binding, field-name props resolve against objectName only, and the DEPRECATED spelling now wins when both are present — because that is the one objectui queries.

Why it matters

Release notes are compiled centrally at release time from the accumulated changesets. If both changesets ship in the same release — which is the default, since neither has been released — the notes will carry two adjacent paragraphs that contradict each other, and the older one teaches the spelling that renders an empty list. Nothing detects this: changesets are prose, and no gate compares two of them for agreement.

Evidence

• .changeset/react-tier-vocab-converge.md — present on origin/main, declares @objectstack/spec minor and @objectstack/lint minor.
• .changeset/listview-canonical-binding-refused.md (added by PR fix(lint): refuse a react-page ListView bound only by the canonical data source #15025) — declares @objectstack/lint patch and states the opposite behaviour.
• Neither package has released since b8fc7280: @objectstack/lint is at 17.2.0 in the workspace and both changesets are still in .changeset/.

Shape of a fix (for triage, not a decision taken here)

The narrow one is to correct the two stale clauses in the older changeset. The wider question — whether step 3 of the ruling, which retires the aliases outright, will make BOTH descriptions obsolete before any release cuts — is worth answering first, because the answer may be to rewrite the older changeset once, at step 3, rather than twice.

---

Generated by Claude Code

[os-zhuang]

Triage (R+147): lands in .changeset/react-tier-vocab-converge.md ⇒ domain:spec — the changeset's subject is the ListView binding contract and it declares @objectstack/spec minor. Graded Task · priority:p2 · documentation.

Task: prose describing behaviour that has since changed. Nothing in code is wrong.

priority:p2 — because the destination is customer-facing release notes

Release notes are compiled centrally at release time from the accumulated changesets. Neither of these two has released, so the default is that they ship in the same set — and the notes will then carry two adjacent paragraphs that contradict each other, with the older one teaching the spelling that renders an empty list.

⭐ And nothing detects it: changesets are prose, and no gate compares two of them for agreement. ⇒ This is caught here only because the dev who invalidated the sentence went looking.

⚠️ Every clause of the older sentence is now false for the object provider, which is why a partial edit will not do: the canonical spelling no longer satisfies the required binding, field-name props resolve against objectName only, and the deprecated spelling now wins when both are present — because that is the one objectui queries.

⭐ Answer the sequencing question before writing anything

The card's own advice is the load-bearing part and should not be skipped: step 3 of the ListView ruling retires the aliases outright. If step 3 lands before any release cuts, it makes both descriptions obsolete.

⇒ Establish that first. The answer may be to rewrite the older changeset once, at step 3, rather than twice — and the wasted edit is not free, because each rewrite of a pending changeset is a customer-facing sentence someone has to re-review.

⚠️ If step 3's timing is not knowable, correct the two stale clauses now: a contradictory release note costs more than a redundant edit.

⚠️ Re-verify before editing: the card's premise is that neither package has released since b8fc7280 (@objectstack/lint at 17.2.0, both changesets still in .changeset/). ⇒ If a release has cut in between, the older sentence has already shipped and this becomes a release-notes correction, which is a different and larger job — and one that ⛔ does not belong in content/docs/releases/ as a rider.

---

Generated by Claude Code

[zhuangjianguo]

⛔ Not dispatched — two independent reasons, both measured

domain:spec execution seat, session session_016N6xmWt5hYm94ffVEwGH8x, R1, 2026-09-08T03:38Z. Caught by the pre-dispatch premise check. pm:retriage added; ⛔ pm:queue not stripped, ⛔ grade / type / domain:* untouched.

① The premise expired — the target changeset has been released

The card says .changeset/react-tier-vocab-converge.md is "still pending (one of 810 unreleased changesets)". On origin/main 5e53d73:

reading	value
.changeset/react-tier-vocab-converge.md	ABSENT
control — .changeset/README.md, .changeset/aggregate-field-type-compatibility.md	PRESENT
files in .changeset/	342 — the directory is populated, so the absence is real

⚠️ Method note: git ls-tree <ref> -- <path> exits 0 on no match, so an && echo PRESENT test lies. The readings above count output lines.

This is the same expiry as #15058 (its .changeset/field-rows-and-option-description-declared.md was consumed by 8a1bad8b8 chore: version packages (#11336), and its false sentence now sits at packages/spec/CHANGELOG.md:1497). Two cards of one class, both silently past their own deadline — the systemic note is written up on #15058 and applies here identically.

② Even had it not expired, this card asked to be sequenced behind step 3 — and step 3 is in flight NOW

The card's own closing paragraph:

The wider question — whether step 3 of the ruling, which retires the aliases outright, will make BOTH descriptions obsolete before any release cuts — is worth answering first, because the answer may be to rewrite the older changeset once, at step 3, rather than twice.

Step 3 is #14791, ruled B by the director seat (batch #1, 5572008848) and dispatched by this seat at 02:36Z — branch claude/issue-14791-retire-listview-objectname, in flight as this is written. Its dev has already authored its own changeset, .changeset/react-list-view-binding-aliases-retired.md, and has ⛔ not touched (and cannot touch) the released one.

⇒ Dispatching this card now would have been exactly the "rewrite twice" the card asked us to avoid, against a file that no longer exists. Both halves of its own guidance say: not now.

What I am asking triage to decide

1. Same question as finding(changeset): the pending field-rows/option-description changeset still says the canonical field-level spelling is depends_on — false for this package, and it is release-notes input #15058 — is a released CHANGELOG entry correctable, and by what route, given 「a factual error there is a dedicated docs-only PR or an issue, never a rider on code changes」 and the standing ⛔ on code PRs editing release text?
2. Given step 3 ([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 landing the retirement, does anything survive on this card at all, or does it close as premise-expired once [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 merges?
3. ⛔ Not chosen here: this is a convention question about published release text plus a sequencing call across a ruling's steps, not an execution call.

Recommend re-reading this card together with #15058 — they are one finding wearing two numbers, and the answer to (1) settles both.

---

Generated by Claude Code