An unreleased changeset states a fact that is now false and will publish it verbatim to the CHANGELOG (.changeset/6794-notify-submitter-default.md)

[os-justin]

Filed by the domain:ui execution-seat PM. Measured and handed up by the objectui#6620 implementing seat (PR #8615), which deliberately did not edit the file — correctly, and the reason is worth preserving. ⛔ Not graded and not assigned.

The defect

.changeset/6794-notify-submitter-default.md is unreleased and still closes with claims about escalation.enabled:

• "installed spec and table agree on it today"
• "whose default flips on a future spec bump"

Both were true when written. Neither is true now. Installed @objectstack/spec is 17.3.0, ApprovalEscalationSchema.safeParse({ timeoutHours: 24 }) yields enabled: true, and PR #8615 has flipped the table's declared default to match. The bump is not future; it happened.

⚠️ A changeset body publishes verbatim into the CHANGELOG. So unless this is corrected before the next release, a published changelog will assert that the spec and the form agree on a key where they had diverged, and describe as future a bump that had already landed.

Why the implementing seat did not just fix it

Quoted, because the reasoning is the useful part and I agree with it:

it is an unreleased changeset owned by the release pipeline, so the in-place-fix exemption's "no other claim holds that file" condition cannot be verified from here, and my own changeset states the corrected fact and lands in the same CHANGELOG section.

⇒ Editing another card's unreleased changeset is not obviously in any single PR's gift. That is a real constraint, not caution.

⚠️ Why the mitigation does not fully cover it

The seat notes that PR #8615's own changeset states the corrected fact in the same CHANGELOG section. That helps, but a section carrying both "the spec and the table agree on this key" and "the table disagreed with the spec, so we flipped it" is confusing rather than self-correcting — a reader has no way to tell which sentence is current. Two statements in one section that contradict each other is a worse artifact than one stale sentence alone.

This has a deadline

⭐ Unlike most findings, this one expires: it is cheap to fix while the changeset is unreleased and impossible afterwards, because a published CHANGELOG entry is not rewritten. Whoever grades it should weigh that against its small size — the priority is low, the window is not.

What is NOT measured

• Whether any other unreleased changeset in .changeset/ carries a claim that has since gone stale. This is very likely not the only one, and a sweep is the higher-value version of this card. I have not run it, and a zero reading would owe a lit control that fires.
• Whether the repo has an existing convention for amending an unreleased changeset owned by another card. If one exists, this is a five-minute fix rather than a question.

Provenance

Measured 2026-09-08 on PR #8615 (card objectui#6620), against installed @objectstack/spec 17.3.0 via the @objectstack/spec/automation subpath — note the root export yields undefined for that schema and throws, which is a separate trap recorded on objectui#6620.

[os-justin]

Second instance, found the same day — this is a class, not an incident

objectui#8044's dev hit the identical shape while landing PR #8669 and reported it rather than fixing it:

.changeset/core-datascope-field-and-comparison-guards-7751.md states, in the present tense, that @object-ui/permissions' evaluateCondition still returns true for { field: 'toString', operator: 'neq' }.

PR #8669 makes that false. It is the fix for exactly that read. If both ship in one release, the changeset publishes the superseded sentence verbatim to the CHANGELOG, describing a fail-open that the same release closes.

Why the dev was right to leave it alone

⛔ It is another card's release note (objectui#7751's), and release notes are written centrally at release time — never accreted or amended by a rider on an unrelated code PR. Rewriting it from PR #8669 would have been the wrong remedy in the same way this card says the first instance's would be.

⇒ Flagged in the PR body for the release editor, and recorded here so the two instances sit under one heading.

What the two instances have in common — and it is the actionable part

Both are an unreleased changeset asserting a present-tense fact about code that a LATER, SEPARATE PR then changes. Neither author did anything wrong: the sentence was true when written, it is load-bearing (it is the justification for the change it accompanies), and nothing re-reads a pending changeset when a subsequent PR falsifies it.

⇒ the gap is that .changeset/*.md is write-once in practice and unread until publish, so the window between "written" and "published" is unguarded — and it is precisely the window in which a fast-moving queue lands the contradicting fix. Two instances in one day on a queue running three agents is the rate this produces.

Worth stating for whoever grades this: the remedy is unlikely to be "check changesets for stale claims" (nothing can know which future PR falsifies which sentence). The tractable version is narrower — a changeset that asserts current behaviour of a package it does not itself change is the shape that rots, and that one is mechanically detectable.

---

Generated by Claude Code