docs(changeset): the consumed page-action-row operation changeset no longer says an api row beside the update parses (deliberate correction) (#23524)

Fixes #23498
Clause-②: no

## What this does

Corrects two sentences of the consumed prerelease changeset
`.changeset/pre/23332-page-action-row-operation.md` in place. PR #23494
(merged as `ad5a7d7c3`) made both false. No code, no new changeset, no
`CHANGELOG.md`, no `content/docs/releases/`, no `.changeset/pre.json`.
The frontmatter, the `Clause-②` line, the ADR-0087 registration marker
and the BREAKING banner are byte-identical. The diff touches lines 24
and 30 only (`+2 / -2`).

## First measurement: the 18.0.0 GA entry is compiled from
`.changeset/pre/`

The card's first step (triage `6171242082`) is measured two ways, on
`1f3ac4f524`:

- **Code.** The repo pins `@changesets/cli` 3.0.3. `@changesets/read`
1.0.1 `readChangesets` reads `.changeset/pre/*` as ids `pre/NAME`.
`@changesets/assemble-release-plan` 7.0.0 `getRelevantChangesets` drops
`pre/` ids only while `preState.mode !== "exit"`. `@changesets/pre`
3.0.0 `exitPre` writes `mode: "exit"`. So on pre-mode exit, every
consumed changeset is an input to the GA release plan.
- **Run.** In a throwaway detached worktree (removed afterwards, nothing
committed), `changeset pre exit && changeset version` exited 0. Its own
notice said: "Please also review the changesets in the .changeset/pre
folder as they will be used as changelogs for the normal versions". The
output set `packages/spec` to `18.0.0`. Its `CHANGELOG.md` `## 18.0.0`
entry (lines 3 to 4266) carried this file's FROM → TO first row at line
3189 and the "What an author now sees" paragraph at line 3195, false
sentence included. So the scope does not shrink to the CHANGELOG line.

## The two sentences, BEFORE → AFTER

| # | where | BEFORE | AFTER |
|:--|:--|:--|:--|
| 1 | FROM → TO, first row, "what to write instead" | the same row
without `onSuccess`: the runner performs the write … | the same row
without `onSuccess`, with no executor key or `'script'` (beside
`operation: 'update'` any other executor is refused at that key, D3
`ui-page-action-row-declarative-update-rules`): the runner performs the
write … |
| 2 | "What an author now sees", closing sentence | The same row without
`onSuccess` parses unchanged. | That row is also refused at
`actionType`, since beside `operation: 'update'` an executor other than
`'script'` is refused (D3
`ui-page-action-row-declarative-update-rules`); without `onSuccess`, and
with no `actionType` or `actionType: 'script'`, it parses. |

**Why:** the example row names `actionType: 'api'`. Since PR #23494, a
page action row carries `ActionSchema`'s declarative-update rules, so an
executor other than `'script'` beside `operation: 'update'` is refused
at the executor key. That holds with or without `onSuccess`. The card's
done-line offered two routes: drop the executor from the example, or
qualify the sentence. This PR qualifies the two sentences. The quoted
refusal text and the example row stay as they were, and the edit stays
within the two places the claim names. Nothing about #23332's own
semantics changes: `onSuccess` beside the update is still refused
whatever executor the row names, or none.

## Every example in the file, parsed against today's `main`

A test-free scratch script (not committed) parsed each shape against
`packages/spec/dist/ui` built from `1f3ac4f524`. The branch's later
merge of `origin/main` brought in no `packages/spec` change (0 paths).

```text
E1 button {actionType:api, operation:update, patch, onSuccess}: REFUSED (2)
   at ["actionType"] `operation: 'update'` is performed by the platform action route … so `actionType` names that route or noth…
   at ["onSuccess"]  An `action:button`'s `onSuccess` (`operation: 'update'`) would follow a result the contract does not declare: the console's action runner reads `operation` befo…
E2 button {actionType:api, operation:update, patch}: REFUSED (1)   (the row the old closing sentence said "parses unchanged")
   at ["actionType"] `operation: 'update'` is performed by the platform action route …
E3 button {operation:update, patch, onSuccess}: REFUSED (1)  at ["onSuccess"]
E4 button {operation:update, patch}: PARSES
E5 button {actionType:script, operation:update, patch, onSuccess}: REFUSED (1)  at ["onSuccess"]
E6 button {actionType:script, operation:update, patch}: PARSES
E7 member {type:api, operation:update, patch}: REFUSED (1)  at ["actions",0,"type"]
E8 member {type:script, operation:update, patch, onSuccess}: REFUSED (1)  at ["actions",0,"onSuccess"]
E9 member {operation:update, patch}: PARSES
E10 button {operation:delete}: REFUSED (1)  at ["operation"] `operation: 'delete'` is a bulk-def operation with no row-level form …
E11 button {operation:custom}: REFUSED (1)  at ["operation"] `operation: 'custom'` is a bulk-def operation with no row-level form …
E12 button {operation:bogus}: REFUSED (1)  at ["operation"] Invalid input: expected "update"
```

After this PR, every statement in the file matches these results. The
FROM → TO first row's "before" is refused (E1). Its "instead" parses
(E4, E6, E9). The "What an author now sees" example gets the quoted
`onSuccess` text (E1), and the new closing sentence names its second
refusal, at `actionType`. The row without `onSuccess` and with no or
`'script'` executor parses (E4, E6). The second and third FROM → TO rows
match E10, E11, E12 and E4.

## `Check Changeset` is red on purpose: DELIBERATE CORRECTION, and a
person's confirmation is owed

`scripts/check-empty-changeset.mjs` refuses a diff that modifies a
changeset present on the merge base. Its git pathspec `.changeset/*.md`
matches `.changeset/pre/` too. Measured locally: exit 1, `::error
file=.changeset/pre/23332-page-action-row-operation.md::`. It names the
two classes. This PR is the **DELIBERATE CORRECTION** class: PR #23494
changed the behaviour this pending release note describes. Remedy, per
the gate: "do NOT restore it -- say so on the PR and get it confirmed".
Nothing here is restored or routed around to turn it green. **A person's
confirmation of this correction is owed on this PR before it lands**, as
on the precedent PR #23126. As on that precedent, no `skip-changeset`
label is applied: #23126 carried none, and its gate stayed red until
confirmed.

`packages/spec/CHANGELOG.md`'s `18.0.0-next.1` entry carries the same
sentence. It was true at `next.1`, and amending it is the release
owner's call. It is not touched here.

## Gates (run at `578a53d33c`)

`node scripts/pm/dispatch-gates.mjs --commands --repo
objectstack-ai/objectstack` derived 20 commands. All 20 were run, plus
`node scripts/check-changeset-fixed.mjs` (its roster lives under
`.changeset/`). `--ran` reconciliation: "20 derived, 20 run, 0
NOT-MEASURED, 0 UNRUN", a DERIVED zero, with every exit code recorded.
Exit 0 for all except `node scripts/check-empty-changeset.mjs --base
origin/main`, which exits 1. That is the designed DELIBERATE CORRECTION
red above. `check-adr-0087-registration --base origin/main`: exit 0.
`check:nul-bytes`: OK. A control-byte self-scan of the edited file found
no hits.

NOT MEASURED locally: the four type-check lanes the derivation names as
CI-only. This diff touches no TypeScript.

## Acceptance notes

- The ADR-0087 marker and the BREAKING banner are left verbatim. The D3
id `ui-page-action-row-declarative-update-rules` named in the new text
is the id of
`packages/spec/src/migrations/entries/semantic/18.ui-page-action-row-declarative-update-rules.ts`.

---

_Generated by [Claude
Code](https://claude.ai/code/session_01D6F9axfoPzR7t8G1J7Ytzz)_

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

Author: objectstack-fleet[bot]

.changeset/pre/23332-page-action-row-operation.md

@@ -21,12 +21,12 @@ The page action rows are `action:button` and `action:icon` (`properties`), and e
 
 | before | what to write instead |
 | --- | --- |
-| `{ actionType: 'api', operation: 'update', patch: { status: 'done' }, onSuccess: { navigate: '/done' } }` (or `type` on a member, or no executor) | the same row without `onSuccess`: the runner performs the write before any executor, so the hop followed a write whose success declares no result |
+| `{ actionType: 'api', operation: 'update', patch: { status: 'done' }, onSuccess: { navigate: '/done' } }` (or `type` on a member, or no executor) | the same row without `onSuccess`, with no executor key or `'script'` (beside `operation: 'update'` any other executor is refused at that key, D3 `ui-page-action-row-declarative-update-rules`): the runner performs the write before any executor, so the hop followed a write whose success declares no result |
 | `{ operation: 'delete', … }` / `{ operation: 'custom', … }` on a row | no `operation`: a row delete is the object's own delete affordance, and a row is already the action a bulk def's `'custom'` would name |
 | any other `operation` value | `operation: 'update'` with a `patch`, or no `operation` (the runner ran nothing for it) |
 
 **The one-line fix: on a page action row, write `operation` only as `'update'`, and never beside `onSuccess`.** `os migrate meta --from 17` lists the D3 entry `ui-page-action-row-operation-declared`; the rewrite is by hand.
 
-**What an author now sees.** `os validate`'s props gate reports the refusal at the row's `operation` or `onSuccess` (`properties.…`, or `properties.actions.N.…` for a member). For example, `{ actionType: 'api', operation: 'update', patch: { status: 'done' }, onSuccess: { navigate: '/done' } }` on an `action:button` gets: ``An `action:button`'s `onSuccess` (`operation: 'update'`) would follow a result the contract does not declare: the console's action runner reads `operation` before any executor, …``. The same row without `onSuccess` parses unchanged.
+**What an author now sees.** `os validate`'s props gate reports the refusal at the row's `operation` or `onSuccess` (`properties.…`, or `properties.actions.N.…` for a member). For example, `{ actionType: 'api', operation: 'update', patch: { status: 'done' }, onSuccess: { navigate: '/done' } }` on an `action:button` gets: ``An `action:button`'s `onSuccess` (`operation: 'update'`) would follow a result the contract does not declare: the console's action runner reads `operation` before any executor, …``. That row is also refused at `actionType`, since beside `operation: 'update'` an executor other than `'script'` is refused (D3 `ui-page-action-row-declarative-update-rules`); without `onSuccess`, and with no `actionType` or `actionType: 'script'`, it parses.
 
 **Measured producers.** None in this repository. In objectui (at its pin `1fb1ced36243` and its main `b9814b3`), the action renderers' own tests carry `operation: 'update'` rows without `onSuccess`, which stay accepted; no row carries another `operation` value or the pairing. objectui's metadata-admin form already clears `onSuccess` when an author switches an action into an update.