Repository navigation
Commit 775ed65
fix(spec)!: a page action row declares ActionSchema's operation and refuses onSuccess beside operation: 'update', with the action's text (#23425)
Fixes #23332
Clause-②: no (narrowing)
The page action rows (`action:button`, `action:icon`, and each
`action:group` / `action:menu` member) and `ActionSchema` now give one
answer for `operation: 'update'` plus `onSuccess`. Direction of record:
triage `6154972534` (consistent with #23168's answer C, `6148462268`),
within the PM's premised ruling.
## Premise check, done first: `ActionSchema`'s refusal is the right half
The ruling's premise: no runtime consumer honors `onSuccess` after an
`operation: 'update'` write as a declared, tested behavior. It holds.
Read at objectui's `.objectui-sha` pin `1fb1ced36243` (the runner file
is byte-identical at objectui `main` `b9814b3`):
- **What the runner does mechanically.** `ActionRunner.execute` reads
`operation` before any executor
(`core/src/actions/ActionRunner.ts:1384-1388`). `executeUpdateOperation`
posts the write through the registered `script` dispatch, and then
`handlePostExecution` runs. That function performs the `onSuccess` hop
for every branch on success (`:1639-1642`). So the hop would fire after
the write, but only because every branch shares the same post-execution
path.
- **It is not declared.** The runner's own docblock for `onSuccess`
(`:1620-1638`) says the key is "refine-scoped to `type: 'api'` and
`type: 'script'`" and that the spec's declared meaning is its only
meaning. objectui's metadata-admin form puts `onSuccess` in
`UPDATE_OPERATION_REFUSES`
(`app-shell/src/views/metadata-admin/inspectors/ActionDefaultInspector.tsx:336-353`),
calls it "a navigation the write has no business doing", and clears it
when an author switches an action into an update (`commitOperation`,
`:620-628`).
- **It is not tested.** No objectui file at the pin pins the pairing.
`ActionRunner.onSuccessNavigation.test.ts` has no `operation` in it, and
`ActionRunner.updateOperation.test.ts` has no `onSuccess`. Of the 55
files that write `operation: 'update'`, the 10 that also mention
`onSuccess` were each read: none puts the two on one action.
So the rule stays as `ActionSchema` has it, and the rows take it. ⛔
`ActionSchema` was not widened.
## What changes
**1. A row's `operation` is `ActionSchema`'s own enum, by reference**
(`component.zod.ts`, `actionOperation()` =
`ActionSchema.in.shape.operation.unwrap()`). It is read the same way
`actionOnSuccessBlock()` reads `onSuccess`, so there is no second
vocabulary: the one member is `'update'`, and `'delete'` / `'custom'`
get the action's own "bulk-def operation with no row-level form"
refusal. Before this, the rows typed it `z.unknown()`. The runner tests
`operation === 'update'` and lets any other value fall through to the
executor, where it did nothing.
**2. A row's `onSuccess` beside `operation: 'update'` is refused
whatever executor the row names (or none)**, as `ActionSchema` refuses
it on every `type`. `refuseRowOnSuccessBesideExecutor` reads `operation`
first, the way the runner does, and gives ONE issue at `onSuccess`.
Before this:
| row | before | after |
| --- | --- | --- |
| `actionType: 'api'` or `'script'` or a host handler, `operation:
'update'`, `onSuccess` | accepted | refused at `onSuccess`, with the
update text |
| no executor, `operation: 'update'`, `onSuccess` | refused with the
no-executor text ("has no executor to follow" … declare `actionType:
'script'`), which does not fit this shape | refused with the update text
|
| `operation: 'update'` and no `onSuccess`, on any executor | accepted |
accepted (unchanged) |
**3. One refusal text, from one place.** The new
`onSuccessBesideUpdateOperationRefusal(subject)` lives in
`action-on-success-executor.ts`, the module PR #23331 created for this
purpose (relative import only, outside the `ui` barrel).
`ActionSchema`'s `DECLARATIVE_UPDATE_REFUSED_KEYS` `onSuccess` entry and
the rows both read it. The text says what the row does at run time, as
the card asks:
> 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, so an `operation: 'update'`
action runs no handler and no executor of its own (the platform action
route writes `patch` to the current record as the caller), and the
runner then performs the post-success hop after that write succeeds.
`${result.*}` reads a handler's return or a call's response, and the
declarative write declares neither. Drop `onSuccess`; post-success
navigation after the declarative write is a spec proposal, not a silent
key.
On `ActionSchema` the subject is "An `operation: 'update'` action's
`onSuccess`". The text used to open "`onSuccess` is not defined for an
`operation: 'update'` action yet". Its reach is unchanged, and the "Drop
`onSuccess`" prescription is kept.
## Accept-set narrowing (BREAKING, `minor`, ADR-0087 `registered
ui-page-action-row-operation-declared`)
Values a row accepted before and now refuses:
- any `operation` other than `'update'`: `'delete'` and `'custom'` (with
the action's prescription), and anything else (`invalid_value`);
- `onSuccess` beside `operation: 'update'`, on any executor.
**Producers measured:** none in this repository at `339604baf`. I
checked `examples/` (the only page action rows are in
`examples/app-showcase/src/ui/pages/index.ts` and
`src/ui/actions/index.ts`, and neither carries `operation`), the CLI
corpus (`packages/cli`, `skills/`) and the dogfood fixtures
(`packages/qa`). In objectui at the pin `1fb1ced36243` and at `main`
`b9814b3`, the action renderers' tests carry `operation: 'update'` rows
without `onSuccess` (accepted, unchanged). No row carries another
`operation` value or the pairing. objectui's registration already
publishes `operation` as `enum: ['update']`
(`action-button.tsx:584-590`), so its `registry-inputs-spec-parity` enum
check gets a member the spec accepts. hotcrm: NOT MEASURED (no checkout
in this container).
Semantic migration entry
`packages/spec/src/migrations/entries/semantic/18.ui-page-action-row-operation-declared.ts`,
beside the `18.ui-page-action-row-*` family. Changeset
`.changeset/23332-page-action-row-operation.md`.
## Pins, each with a negative control
- **Row side** (`component-action-row-on-success-executor.test.ts` §4),
on all four rows:
- REFUSAL: `onSuccess` beside `operation: 'update'` with no executor and
with `api` / `script` / `run`. The test asserts ONE issue at `onSuccess`
plus the full first sentence.
- NEGATIVE CONTROL: the same rows without `onSuccess` parse.
- ONE TEXT: the row message after its subject equals `ActionSchema`'s
message after its subject.
- NO SECOND VOCABULARY: every row holds the very enum instance
`ActionSchema.operation` declares.
- `'delete'` is refused with the action's exact message, `'create'` gets
`invalid_value` at `operation`, and the `'update'` accepted control
passes.
- **`ActionSchema` side** (`action-row-update.test.ts`):
- The mixing-rule pin is flipped to the new opening, a prefix of the
text that bears the load.
- New: `onSuccess` beside `operation: 'update'` (no `type` and explicit
`type: 'script'`) gives exactly one issue, at `onSuccess`, and the same
action without it parses.
- **The `os validate` door**
(`packages/lint/src/validate-component-props-row-on-success.test.ts`):
one `component-props-invalid` finding at `…onSuccess` for `api` + update
+ `onSuccess`, nothing without `onSuccess`, and one finding at
`…operation` for `'delete'`.
- **Ledger:** `component-props-unknown-members.pin.test.ts` deletes the
`operation` line, because a typed member deletes its line.
**Pin sweep:** I grepped the old message ("not defined for an
`operation: 'update'`") across this repo: one pin, flipped
(`action-row-update.test.ts:218`). objectui at the pin and at `main`:
zero hits.
**Ablations** (committed tree, `scripts/ablation-replace.mjs`; every leg
restored to blob == HEAD with `git diff HEAD` empty; spec tests import
`src`, so no dist was involved):
- The row branch was turned off (`if (row.operation === 'update')`
changed to `if (false as boolean)`). Result: 20 red (16 REFUSAL + 4 ONE
TEXT), and the negative controls stayed green.
- `ActionSchema`'s `onSuccess` entry was deleted. Result: 6 red (both
`ActionSchema` pins + 4 ONE TEXT). My first attempt used an empty
`--replacement`, which the tool refused as a no-op (count 0 to 0). It
was re-run with `--delete`.
- The row enum was replaced by `z.unknown()`. Result: 9 red (8 operation
refusals + NO SECOND VOCABULARY).
## Verification at `339604baf` (after merging `origin/main` `5656c5638`)
- `@objectstack/spec`:
- Targeted files after the merge rebuild: 4 files, 289 passed.
- `--project local`: 672 of 673 files green before the ledger fix. The 3
failures were all in `component-props-unknown-members.pin.test.ts` (the
typed `operation` member's line), and that file is now 69/69.
- `test:repo`: 59 files, 1011 passed.
- `typecheck` (tsc, scripts, test-typecheck): exit 0.
- `check:generated`: green after `gen:docs`
(`content/docs/references/ui/component.mdx` regenerated).
- `@objectstack/lint`: 138 files, 6706 passed; `typecheck`: exit 0.
- Consumer readings (`ComponentPropsMap` parsers): `cloud-connection`
and `mcp` `canonical-expression-envelopes.test.ts` 16 and 11 passed;
`platform-objects` `pages/canonical-expression-envelopes.test.ts` 15
passed.
- `dispatch-gates.mjs --commands`: 111 families, all 111 run on
`339604baf`, every one exit 0. `--ran` reconciliation: "111 run, 0
NOT-MEASURED (a DERIVED zero — all 111 recorded an exit code and none of
them is 3)". `check:nul-bytes` exit 0.
## Acceptance notes
- Out of scope, same family (rows vs `ActionSchema` on the
declarative-update mixing rule): the rows carry none of `ActionSchema`'s
other `operation: 'update'` refusals. These were measured on the built
spec: `patch` without `operation`, `target` beside update, a non-script
executor beside update, update with nothing to write, and `list_toolbar`
beside update each parse on `action:button` and are refused by
`ActionSchema`. Reported to the seat for the family's closing card. Not
fixed here.
- Not touched: `packages/spec/src/ui/page.zod.ts` (#23357). The sentence
at `component.zod.ts:6030` ("a stored page still saves and loads") is
far from this diff and still true until #23418 lands, so it was left
alone. The new migration entry's sentence "A page's `properties` is not
parsed on the metadata save or load path" follows its family's current
text, and #23418 rewrites that text in the sibling entries. Whichever PR
lands later should align this entry too.
- `Clause-②`: the PM's claim declared `yes`, conservatively and
conditionally ("if measurement moves the rule on ActionSchema's side,
which would widen it"). Measurement did not move it, so this PR declares
`no (narrowing)`, as triage's direction records for this outcome.
---
_Generated by [Claude
Code](https://claude.ai/code/session_01D6F9axfoPzR7t8G1J7Ytzz)_
---------
Co-authored-by: Claude <noreply@anthropic.com>1 parent 823da2f commit 775ed65
10 files changed
Lines changed: 281 additions & 25 deletions
File tree
- .changeset
- content/docs/references/ui
- packages
- lint/src
- spec/src
- migrations/entries/semantic
- ui
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
| 1 | + | |
| 2 | + | |
| 3 | + | |
| 4 | + | |
| 5 | + | |
| 6 | + | |
| 7 | + | |
| 8 | + | |
| 9 | + | |
| 10 | + | |
| 11 | + | |
| 12 | + | |
| 13 | + | |
| 14 | + | |
| 15 | + | |
| 16 | + | |
| 17 | + | |
| 18 | + | |
| 19 | + | |
| 20 | + | |
| 21 | + | |
| 22 | + | |
| 23 | + | |
| 24 | + | |
| 25 | + | |
| 26 | + | |
| 27 | + | |
| 28 | + | |
| 29 | + | |
| 30 | + | |
| 31 | + | |
| 32 | + | |
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
43 | 43 | | |
44 | 44 | | |
45 | 45 | | |
46 | | - | |
| 46 | + | |
47 | 47 | | |
48 | 48 | | |
49 | 49 | | |
| |||
54 | 54 | | |
55 | 55 | | |
56 | 56 | | |
57 | | - | |
| 57 | + | |
58 | 58 | | |
59 | 59 | | |
60 | 60 | | |
| |||
101 | 101 | | |
102 | 102 | | |
103 | 103 | | |
104 | | - | |
| 104 | + | |
105 | 105 | | |
106 | 106 | | |
107 | 107 | | |
| |||
110 | 110 | | |
111 | 111 | | |
112 | 112 | | |
113 | | - | |
| 113 | + | |
114 | 114 | | |
115 | 115 | | |
116 | 116 | | |
| |||
137 | 137 | | |
138 | 138 | | |
139 | 139 | | |
140 | | - | |
| 140 | + | |
141 | 141 | | |
142 | 142 | | |
143 | 143 | | |
| |||
146 | 146 | | |
147 | 147 | | |
148 | 148 | | |
149 | | - | |
| 149 | + | |
150 | 150 | | |
151 | 151 | | |
152 | 152 | | |
| |||
191 | 191 | | |
192 | 192 | | |
193 | 193 | | |
194 | | - | |
| 194 | + | |
195 | 195 | | |
196 | 196 | | |
197 | 197 | | |
| |||
200 | 200 | | |
201 | 201 | | |
202 | 202 | | |
203 | | - | |
| 203 | + | |
204 | 204 | | |
205 | 205 | | |
206 | 206 | | |
| |||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
108 | 108 | | |
109 | 109 | | |
110 | 110 | | |
| 111 | + | |
| 112 | + | |
| 113 | + | |
| 114 | + | |
| 115 | + | |
| 116 | + | |
| 117 | + | |
| 118 | + | |
| 119 | + | |
| 120 | + | |
| 121 | + | |
| 122 | + | |
| 123 | + | |
| 124 | + | |
| 125 | + | |
| 126 | + | |
| 127 | + | |
| 128 | + | |
| 129 | + | |
| 130 | + | |
| 131 | + | |
| 132 | + | |
| 133 | + | |
| 134 | + | |
| 135 | + | |
| 136 | + | |
0 commit comments